(19) 



J 



(12) 



(43) Date of publication: 

09.02.2000 Bulletin 2000/06 



Europaisches Patentamt 
European Patent Office 
Off ice europSen des brevets (11) EP 0 979 007 A2 

EUROPEAN PATENT APPLICATION 

(51) Int. CI. 7 : H04N7/01 



(21 ) Application number: 99121649.0 

(22) Date of filing: 13.10.1994 



(84) 


Designated Contracting States: 


* Ostrover, Lewis S. 




AT BE CH DE DK ES FR GB GR IE IT LI LU MC NL 


Los Angetes, CA 90027 (US) 




PTSE 


• Lieberfarb, Warren N. 




Designated Extension States: 


Los Angeles, CA 90077 (US) 




LTSI 








(74) Representative: 


(30) 


Priority: 29.10.1993 US 144792 


Hackett, Sean James 






Marks & Clerk, 


(62) 


Document number(s) of the earlier application(s) in 


Alpha Tower, 




accordance with Art. 76 EPC: 


Suffolk Street Queensway 




94931887.7/0 683 956 


Birmingham B1 1TT (GB) 


(71) 


Applicant: 


Remarks: 




TIME WARNER ENTERTAINMENT CO., L.P. 


This application was filed on 02 - 1 1 - 1 999 as a 




Burbank, CA 91522 (US) 


divisional application to the application mentioned 






under INID code 62. 


(72) 


Inventors: 




• 


Cookson, Christopher J. 






Los Angeles, CA 90046 (US) 





CM 
< 

o 

o> 

o> 
o 

CL 
UJ 



(54) System for generating multiple aspect ratio signals from motion picture disk recorded in a 
single aspect ratio 



(57) A system for generating a video signal in a 
selected one of multiple aspect ratios from play of a disk 
on which is recorded a motion picture in only one aspect 
ratio. The disk includes a code indicative of the recorded 
aspect ratio, and the player has a default aspect ratio 
setting which can be changed by the user. Typically, the 
recorded aspect ratio is 16:9, center cut 4:3, pan scan 
4:3, and letter box aspect ratios. The player automati- 
cally generates the appropriate video signal in accord- 
ance with both its default aspect ratio setting and the 
disk code. 
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Description 

[0001] This invention relates to the generation of a 
video signal from play of a software (e.g., motion pic- 
ture) carrier, and more particularly to a technique by s 
which a video signal can be generated in a selected one 
of multiple aspect ratios upon play of a disk recorded in 
only a single aspect ratio. 

Background Of The Invention 10 

[0002] There are three primary color transmission 
standards in use today. The 525-line, 30-f rame-per-sec- 
ond NTSC (National Television Systems Committee) 
standard is used in the United States, Canada, Central is 
America, most of South America, and Japan. The 625- 
line, 25-frames-per-second PAL (Phase Alternation 
Each Line) standard is used in England, most countries 
and possessions influenced by the British Common- 
wealth, many western European countries and China. 20 
Finally, the 625-line, 25-frames-per-second SECAM 
(Sequential Color With [Avec] Memory) standard is 
used in France, countries and possessions influenced 
by France, the former Soviet Bloc nations including East 
Germany, and other areas influenced by them. Other 25 
standards are becoming available, such as HDTV (High 
Definition Television). The video signal according to 
each standard is unique, and an ordinary television 
receiver designed to process a video signal of one type 
cannot process a video signal of another. 30 
[0003] If a software publisher wants to make a pro- 
gram such as a motion picture available in more than 
one aspect ratio, the publisher typically prepares a dif- 
ferent program version for each. This further increases 
the number of versions which may have to be produced. 35 
Each version of a motion picture must be identified not 
only by a video standard, but now also by an aspect 
ratio. Thus there are available on the market, for exam- 
ple, NTSC 4:3 "letter box," NTSC 4:3 "pan scan," "Hi- 
Vision" 16:9 wide screen HDTV, etc. versions of the 40 
same motion picture. Since prepackaged media such 
as laserdiscs, VHS tapes, CD-ROMs, etc. are limited in 
terms of how much total material can be stored, it is not 
feasible to provide more than one aspect ratio version of 
a program on a given storage medium. That is why 45 
when different aspect ratio versions of motion picture 
releases are made available, they are made available 
on different dedicated media. 

[0004] Digitally encoded optical disks are in theory far 
superior for the distribution of motion pictures and other so 
forms of presentation. Especially advantageous is the 
use of "compressed video," by which it is possible to 
digitally encode a motion picture on a disk no larger 
than the present-day audio CD. Unfortunately, while 
much effort has been expended in developing com- ss 
pressed video systems, relatively little attention has 
been paid to aspect ratio considerations. A motion pic- 
ture may be efficiently represented on an optical disk, 



for example, but the intent is for the motion picture to 
play in only the aspect ratio recorded on the disk. 
Depending on the particular television receiver and disk 
player that a consumer has, it is generally necessary to 
purchase a disk whose program material is recorded in 
the particular aspect ratio. This, in turn, means that the 
software publisher must make available multiple version 
disks each having a motion picture recorded in a 
respective aspect ratio, 

[0005] It is therefore an object of this invention to pro- 
vide a system and method for a software publisher to 
record on a software carrier, such as an optical disk, a 
motion picture in a single aspect ratio, but to play that 
disk on a player which can generate a video signal in a 
selected one of multiple aspect ratios. 

Summary Of The Invention 

[0006] In accordance with the principles of the inven- 
tion, a software publisher provides a software carrier 
which contains digital data representative of a motion 
picture having a base aspect ratio. Preferably, the base 
aspect ratio is a 16:9 'Wide screen" image. (It is to be 
understood that the invention is not limited to a particu- 
lar medium, and it is applicable to tape carriers and all 
digital storage media, not just the optical disks of the 
illustrative embodiment of the invention. Nor is the 
invention limited only to the distribution of motion pic- 
tures. For example, in an extreme case, the invention is 
applicable to the distribution of a library of still pictures, 
in which case there is no "motion" at all. The term "soft- 
ware publisher" thus embraces much more than a 
motion picture company, and the term "carrier" 
embraces much more than a digitally encoded optical 
disk.) 

[0007] The player is designed to process the digital 
data read from the carrier and to generate a corre- 
sponding analog video signal. The carrier contains a 
code indicative of the recorded aspect ratio. (There is no 
invention per se in having the carrier include data which 
is indicative of the recorded aspect ratio. The issue is 
what the player does with the information.) The player 
can generate the video signal in the same wide screen 
aspect ratio represented on the carrier. However, the 
user of the player can select a different aspect ratio. 
One such aspect ratio is 4:3 letter box. The conversion 
can be best understood by considering two rectangles 
having the same height but respective width:height 
ratios of 16:9 and 4:3. If the former is reduced in size so 
that it can be wholly contained within the latter, it is 
apparent that the vertical sides of the 16:9 image must 
be brought closer together. This, in turn, results in the 
top and bottom sides also being brought closer 
together. When the reduced-sized 16:9 image is cen- 
tered in the 4:3 rectangle, there are left-over bands at 
the top and at the bottom. Similarly, when a wide screen 
motion picture is displayed on a conventional 4:3 aspect 
ratio television receiver, the top and bottom of the 
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screen are usually blanked (dark). 
[0008] But an alternative to reducing a 16:9 image so 
that it fits on a 4:3 screen is to display just a 4:3 cut from 
the wide screen image. Given 16:9 image and 4:3 
screen rectangles of the same height, it is apparent that s 
when the smaller screen rectangle is placed on the 
larger image rectangle, the only picture information 
which is displayed is that within the 4:3 rectangle. What 
is lost in such a case is picture information on the left 
side or the right side, or both sides, of the wide screen 
image. One way in which to convert from a 16:9 to a 4:3 
aspect ratio (and to fill up the 4:3 screen rather than to 
blank out the top and bottom of the screen as in a letter 
box presentation) is to select the middle part (a "center 
cut") of each wide screen image for display, in effect 
deleting equal sections from the left and right sides of 
the original image. 

[0009] The invention, however, provides for a more 
sophisticated control over which part of the wide screen 
image is selected for viewing. The software carrier itself 
contains pan scan information which can change from 
one part of a motion picture to another. Referring to the 
discussion above about fitting a 4:3 screen rectangle on 
a larger 16:9 image rectangle to determine how much of 
the wide screen image is actually selected for viewing, a 
pan scan of the wide screen image involves moving the 
4:3 rectangle in the horizontal direction. If the rectangle 
is all the way to the left, then what is deleted is the right 
side of the wide screen image. Alternatively, moving the 
4:3 rectangle all the way to the right cuts out the left part 
of the wide screen image. But the 4:3 rectangle can be 
moved anywhere between the two extremes. This 
allows the software publisher to choose which part of 
the wide screen image is displayed at any given time. 
The disk of the invention can be provided with continu- 
ously changing pan scan information representative of 
what vertical line through the wide screen image corre- 
sponds to the left edge of the 4:3 rectangle selected for 
viewing. The player of the invention automatically gen- 
erates a video signal which represents the selected part 
of the wide screen image. (From an engineering point of 
view, it is well known in the art how to accomplish a pan 
scan. For example, this is the way software publishers 
today sometimes reduce a wide screen motion picture 
to a 4:3 aspect ratio for recording on a software carrier. 
It is because conventional players cannot convert a 
wide screen aspect ratio on a carrier to multiple aspect 
ratios required for display on different television receiv- 
ers, thus making it necessary to produce a unique car- 
rier for each aspect ratio, preferably with a pan scan of 
the wide screen original, that there is need for the 
present invention.) 

[001 0] The player of the illustrative embodiment of the 
invention plays disks recorded in one of only two aspect 
ratios, 16:9 or 4:3. (These are today's "standard" elec- 
tronic display formats, but it should be understood that 
the principles of the invention are equally applicable to 
other aspect ratios.) These two aspect ratios, however, 
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give rise to more than just two possibilities. As 
described above, the output aspect ratio can be the 
original 16:9 in letter box form, the output can be a 4:3 
center cut from a 16:9 wide screen image, or the output 
can be a pan scan cut from the original. (Of course, the 
output can also be in the original 16:9 format.) The 
player has a default aspect ratio, by which is meant that 
the player automatically generates a video signal having 
the default aspect ratio. The user can change the default 
setting. The advantage of providing a default setting is 
that play is automatic and the user has one less control 
to worry about. Only in the case of an ambiguity is the 
user asked for his preference. For example, if the player 
default is pan scan 4:3 and the disk is recorded in a 1 6:9 
aspect ratio but does not contain pan scan update infor- 
mation, then the player has no way of knowing which 
part of the wide screen image should be played. In such 
a case, the user is given a choice between a center cut 
and a letter box form of display. 

[0011] The invention offers an additional benefit to 
motion picture companies. It might be thought that with 
"universal" players in the hands of consumers, players 
which can generate video signals not only in multiple 
standards (as will be described below) but also with dif- 
ferent aspect ratios, a motion picture company would 
distribute disks recorded only in a wide screen format - 
this base aspect ratio allows for the generation of the 
best possible picture for all TV receivers (e.g., wide 
screen for wide screen receivers, reduced aspect ratios 
for older type receivers, etc.). However, a motion picture 
company may deliberately release a '1 ilm" having a 4:3 
aspect ratio. This allows for the release at a later date of 
an "improved" version with a wide screen aspect ratio, 
and perhaps other enhancements as well. The point is 
that if consumers have players that can generate video 
signals in a selected one of many different aspect ratios, 
then the software publishers can re-release programs in 
improved formats and thus make additional sales. 
[0012] Nevertheless, the main advantage of the inven- 
tion is that a software publisher no longer will have to 
release dedicated aspect ratio versions of the same 
motion picture. Because of inventory, cost, promotion, 
contractual or financial considerations in releasing mul- 
tiple versions of the same program, some publishers 
today do not or cannot release dedicated aspect ratio 
versions of all titles, and some distributors and retailers 
do not or cannot stock them. The present invention 
overcomes these problems because a single recording 
will allow video signals to be generated in multiple 
aspect ratios. 

[001 3] It should also be appreciated that the invention 
is almost the converse of that taken in the design of cer- 
tain wide screen television receivers now being mar- 
keted in the United States and Japan under the 
trademarks Thomson, Toshiba, JVC and others. These 
television receivers take a 4:3 image, the most prevalent 
standard today, and blow it up to fill the 16:9 screen. 
Separate and apart from image degradation which can 
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be seen on the screen, such an approach involves a 
conversion from 4:3 to 16:9, rather than the reverse. 
One of the goals of the invention is to provide on the car- 
rier an aspect ratio from which many others may be 
derived with minimum degradation of the image. It is 
therefore better to start with "more" on the disk than 
"less," i.e., to go from 16:9 to 4:3. 
[0014] The invention is disclosed in the context of an 
overall system which offers numerous advantageous 
features. The entire system is described although the 
appended claims are directed to specific features. The 
overall list of features which are of particular interest in 
the description below include: 

Video standard and territorial lock out 

Play in multiple aspect ratios. 

Play of multiple versions, e.g., PG -rated and R- 

rated, of the same motion picture from the same 

disk, with selective automatic parental disablement 

of R-rated play. 

Encrypted authorization codes that prevent unau- 
thorized publishers from producing playable disks. 
Provision of multiple-language audio tracks and 
multiple-language subtitle tracks on a single disk, 
with the user specifying the language of choice. 
Provision of multiple "other" audio tracks, e.g., each 
containing some component of orchestral music, 
with the user choosing the desired mix. 
Variable rate encoding of data blocks, and efficient 
use of bit capacity with track switching and/or mix- 
ing, to allow all of the above capabilities on a single 
carrier. 

[0015] Further objects, features and advantages of 
the invention will become apparent upon consideration 
of the following detailed description in conjunction with 
the drawing, in which: 

FIG. 1 depicts a prior art system and typifies the 

lack of flexibility in, and the poor performance of, 

presently available media players; 

FIG. 2 depicts the illustrative embodiment of the 

invention; 

FIG. 3 is a chart which lists the fields in the lead-in 
portion of the digital data track of an optical disk 
that can be played in the system of FIG. 2; 
FIG. 4 is a similar chart which lists the fields in each 
of the data blocks which follow the lead-in track sec- 
tion of FIG. 3; 

FIGS. 5A-5E comprise a flowchart that illustrates 
the processing by the system of FIG. 2 of the data 
contained in the lead-in track section of an optical 
disk being played; 

FIG. 6 is a flowchart that illustrates the processing 
of the data blocks, in the format depicted in FIG. 4, 
that follow the lead-in section of the track; 
FIG. 7A is a state diagram and legend that charac- 
terize the manner in which the player of the inven- 



tion reads only those data blocks on a disk track 
that are required for the play of a selected version of 
a motion picture or other video presentation, and 
FIG. 7B depicts the way in which one of two alter- 

5 nate versions can be played by following the rules 
illustrated by the state diagram of FIG. 7A; 
FIG. 8 depicts symbolically a prior art technique 
used in compressing the digital representation of a 
video signal; and 

10 FIG. 9 illustrates the relationships among three dif- 
ferent image aspect ratios. 

The Prior Art 

is [0016] The limitations of the prior art are exemplified 
by the system of FIG. 1. Such a system is presently 
available for playing a single source of program mate- 
rial, usually a VHS videocassette, to generate a video 
signal conforming to a selected one of multiple stand - 

20 ards. A system of this type is referred to as a multi- 
standard VCR, although stand-alone components are 
shown in the drawing. Typically, a VHS tape 7 has 
recorded on it an NTSC (analog) video signal, and the 
tape is played in a VHS player 5. The analog signal is 

25 converted to digital form in A/D converter 9, and the dig- 
ital representations of successive frames are written 
into video frame store 1 1 . Circuit 1 3 then deletes excess 
frames, or estimates and adds additional frames, nec- 
essary to conform to the selected standard, e.g., PAL. 

30 To convert from one standard to another, it is generally 
necessary to change the number of horizontal lines in a 
field or frame (image scaling). This is usually accom- 
plished by dropping some lines, and/or repeating some 
or averaging successive lines to derive a new line to be 

35 inserted between them. The main function of circuit 13, 
of course, is to convert a digital frame representation to 
analog form as the video output. 
[0017] Systems of the type shown in FIG. 1 generally 
degrade the video output. Conventional videocassettes 

40 deliver reduced quality video when they support more 
than one video standard. One reason is that there is a 
double conversion from analog to digital, and then back 
again. Another is that the image scaling is usually per- 
formed in a crude manner (deleting lines, repeating 

45 lines and averaging lines). There are known ways, how- 
ever, to perform image scaling in the digital domain with- 
out degrading the picture. While not generally used, the 
technique is in the prior art and will therefore be 
described briefly as it is also used in the illustrative 

so embodiment of the invention. 

[0018] To give a concrete example, the PAL standard 
has 625 lines per frame, while the NTSC standard has 
525 lines per frame. Because no part of the image is 
formed during the vertical retrace, not all of the horizon- 

55 tal line scans in either system are usable for represent- 
ing image information. In the PAL standard there are 
nominally 576 lines per frame with image information, 
and in an NTSC frame there are nominally 483 lines 
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with image information. 

[0019] To convert from one standard to another, suc- 
cessive fields are first de-interlaced. Then 576 lines are 
convened to 483, or vice versa, and re-interlaced. How 
this is done is easy to visualize conceptually. Consider, 
for example, a very thin vertical slice through a PAL 
frame. The slice is broken down into its three color com- 
ponents. Image scaling for converting from PAL to 
NTSC. from a conceptual standpoint, is nothing more 
than drawing a curve based on 576 PAL pieces of color 
data and then dividing the curve into 483 parts to derive 
a piece of data for each horizontal line of the desired 
NTSC signal. In actuality, this is accomplished by a 
process of interpolation, and it is done digitally. (Image 
scaling, in general, may also involve a change in the 
aspect ratio, for example, in going from HDTV to NTSC, 
and may require clipping off information at both ends of 
every horizontal line.) 

[0020] While prior art systems thus do provide for 
standards conversion, that is about the extent of their 
flexibility. The system of FIG. 2, on the other hand, offers 
unprecedented flexibility in ways not even contemplated 
in the prior art. 

The Illustrative System Of The Invention 

[0021] The system of FIG. 2 includes a disk drive 21 
for playing an optical disk 23. Digital data stored on the 
disk appears on the DATA OUT conductor 25. The disk 
drive operation is governed by microprocessor disk 
drive controller 27. The read head is positioned by com- 
mands issued over HEAD POSITION CONTROL lead 
29, and the speed of the disk rotation is governed by 
commands issued over RATE CONTROL conductor 31 . 
Optical disks are usually driven at either constant linear 
velocity or constant angular velocity. (Another possibility 
involves the use of a discrete number of constant angu- 
lar velocities.) Disks of the invention may be driven at 
constant linear velocity so that the linear length of track 
taken by each bit is the same whether a bit is recorded 
in an inner or outer portion of the track. This allows for 
the storage of the most data. A constant linear velocity 
requires that the rate of rotation of the disk decrease 
when outer tracks are being read. This type of optical 
disk control is conventional. For example, the CD audio 
standard also requires disks which are rotated at a con- 
stant linear rate. 

[0022] Microprocessor 41 is the master controller of 
the system. As such, it issues commands to the disk 
drive controller over conductor 43 and it determines the 
status of the disk drive controller over conductor 45. The 
disk drive controller is provided with two other inputs. 
Block number/pointer analyzer 47 issues commands to 
the disk drive controller over conductor 49, and 
BUFFER FULL conductor 51 extends a control signal 
from OR gate 54 to the disk drive controller. These two 
inputs will be described below. (In general, although ref- 
erence is made to individual conductors, it is to be 
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understood that in context some of these conductors 
are in reality cables for extending bits in parallel. For 
example, while the output of OR gate 54 can be 
extended to the disk drive controller over a single con- 
s ductor 51, block number/pointer analyzer 47 could be 
connected to the disk drive controller over a cable 49 so 
that multi-bit data can be sent in parallel rather than 
serially.) 

[0023] An important feature of the system of FIG. 2 is 

10 that bit information is stored on the disk at a rate which 
varies according to the complexity of the encoded mate- 
rial. By this is meant not that the number of bits per sec- 
ond which actually appear on the DATA OUT conductor 
25 varies, but rather that the number of bits which are 

15 used per second varies. Video information is stored in 
compressed digital form. FIG. 8 shows the manner in 
which video frames are coded according to the MPEG1 
and MPEG2 standards. An independent l-frame is 
coded in its entirety. Predicted or P-frames are frames 

20 which are predicted based upon preceding independent 
frames, and the digital information that is actually 
required for a P frame simply represents the difference 
between the actual frame and its prediction. Bidirection- 
ally predicted B-frames are frames which are predicted 

25 from I and/or P frames, with the information required for 
such a frame once again representing the difference 
between the actual and predicted forms. (As can be 
appreciated, fast forward and fast reverse functions, if 
desired, are best implemented using l-frames.) The 

30 number of bits required to represent any frame depends 
not only on its type, but also on the actual visual infor- 
mation which is to be represented. Obviously, it requires 
far fewer bits to represent a blue sky than it does to rep- 
resent a field of flowers. The MPEG standards are 

35 designed to allow picture frames to be encoded with a 
minimal number of bits. Frame information is required at 
a constant rate. For example, if a motion picture film is 
represented in digital form on the disk, 24 frames will be 
represented for each second of play. The number of bits 

40 required for a frame differs radically from frame to 
frame. Since frames are processed at a constant rate, it 
is apparent that the number of bits which are processed 
(used) per second can vary from very low values to very 
high values. Thus when bits are actually read from the 

45 disk, while they may be read from the disk at a constant 
rate, they are not necessarily processed at a constant 
rate. 

[0024] Similar considerations apply to any audio 
stored on the disk. Any data block may contain the bit 

so information required for a variable number of image 
frames. Any data block may similarly contain the bit 
information required for a variable time duration of a var- 
iable number of even numerous audio tracks. (There is 
just one physical track. The reference to multiple audio 

55 tracks is to different series of time-division slices con- 
taining respective audio materials.) The audio tracks 
contain digital information, which may also be in com- 
pressed form. This means that if there is information 
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stored in any data block for a particular audio track, 
those bits do not necessarily represent the same time 
duration. It might be thought that the duration of the 
sound recorded for any audio track corresponding to 
any picture frames represented in a block would be the 
duration of the picture frames. However, that is not nec- 
essarily true. This means that audio information may be 
read before it is actually needed, with the reading of 
more audio information pausing when a sufficient 
amount has already accumulated or with audio not 
being included in some data blocks to compensate for 
the preceding over-supply. This leads to the concept of 
buffering, the function of audio buffers 53, video buffer 
55, pan scan buffer 57, subtitle buffer 59, and OR gate 
54 which generates the BUFFER FULL signal. 
[0025] As each data block is read from the disk, it 
passes through gate 61 . provided the gate is open, and 
the bit fields are distributed by demultiplexer 63 to the 
various buffers and, over the COMMAND/DATA line 65, 
to master controller 41. Each data block in the illustra- 
tive embodiment of the invention contains video bit 
information corresponding to a variable number of pic- 
ture frames. As discussed above, there may be a large 
number of bits, or a small number, or even no bits (for 
example, if the particular disk being played does not 
represent any video). Successive groups of video data 
are stored in video buffer 55 separated by markers. 
Video decoder 67 issues a command oyer conductor 69 
when it wants to be furnished with a new batch of data 
over conductor 71 . Commands are issued at a steady 
rate, although the number of bits furnished in reply vary 
in accordance with the number of bits required for the 
particular frames being processed. The rate at which 
bits are read from the disk drive is high enough to 
accommodate frames which require maximal informa- 
tion, but most frames do not. This means that the rate at 
which data blocks are actually read is higher than the 
rate at which they are used. This does not mean, how- 
ever, that a well<iesigned system should delay reading 
of a block of data until the data is actually required for 
processing. For one thing, when data is actually 
required, the read head may not be positioned at the 
start of the desired data block. It is for this reason that 
buffering is provided. The video buffer 55 contains the 
bit information for a number of successive frames (the 
actual number depending upon the rate at which bits 
are read, the rate at which frames are processed, etc., 
as is known in the art), and video data block information 
is read out of the video buffer at a constant frame rate 
determined by video decoder 67. Video data is deliv- 
ered to the buffer only until the buffer is full. Once the 
buffer is full, no more information should be delivered 
because it cannot be stored. When the video buffer is 
full, a signal on conductor 69 causes the output of OR 
gate 54 to go high to inform disk drive controller 27 that 
one of the buffers is full. 

[0026] Similar remarks apply to the three other types 
of buffers. (There is a single subtitle buffer 59, a single 



pan scan buffer 57, and numerous audio buffers 53, the 
purpose of all of which will be described below.) When 
any of these buffers is full, its corresponding output 
causes OR gate 54 to control the BUFFER FULL con- 

5 ductor to go high and to so inform the disk drive control- 
ler that one of the buffers is full. Audio buffers 53 and 
subtitle buffer 59 operate in a manner comparable to 
that described for video buffer 55. Audio processor 
decoder 71 issues a command to the audio buffers 

10 when it requires audio track data, at which time the 
audio buffers furnish such data. Similarly, graphics gen- 
erator 73 retrieves data from subtitle buffer 59, and pan 
scan processor/vertical scaler 87 receives data from 
pan scan buffer 57 as will be described below. 

is [0027] When any one of the four buffers is full (which 
includes any one of the individual buffers within the 
block 53), the disk drive controller 27 causes the disk 
drive to stop reading data. Data is not read again until all 
of the buffers can accept it, i.e., until no buffer is full and 

20 conductor 51 goes low. (Conversely, if the buffers are 
being depleted of data too rapidly, an adjustment in the 
RATE CONTROL signal on conductor 31 increases the 
disk speed and thus the rate at which the buffers are 
filled.) 

25 [0028] This discussion of buffering arose from a con- 
sideration of the BUFFER FULL input 51 to the disk 
drive controller 27. The other input which remains to be 
described is that represented by cable 49. As will be 
described below, every data block has a serial block 

30 number as well as pointer information at its beginning. 
Circuit 47 reads the serial block number and analyzes 
the pointer information. The pointer, a serial block 
number, points to the next data block which should be 
read. This information is furnished to the disk drive con- 

35 troller over cable 49. It is in this way that the disk drive 
controller can control positioning of the read head of the 
disk drive so that the desired data block can be 
accessed. Many times the wrong block will be read - 
this is to be expected in the case of a jump to a new 

40 block, as is the case, for example, when a jump is made 
from one track to another when playing a CD audio disk. 
If the disk drive reads a data block whose serial block 
number is too high or too low, this is determined by 
block number/pointer analyzer 47 which then issues a 

45 new command over cable 49 to the disk drive controller 
to cause it to read another block with a lower or higher 
serial block number respectively. During the time that 
the read head is positioning itself to read a new block, 
the data which is read is not actually used. Gate 61 

so remains closed so that the information is not delivered 
to the demultiplexer 63 for distribution to the four buffers 
and to the master controller 41 over the COM- 
MAND/DATA lead. It is only when the correct data block 
is reached, as determined by circuit 47 analyzing the 

55 serial block number at the start of the block that con- 
ductor 75 is pulsed high to open gate 61 . 
[0029] The remainder of the block is then delivered to 
the demultiplexer. The data bits read from the disk are 
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also delivered to the microprocessor master controller 
41 over conductor 77. Each data block contains not only 
bit information which must be distributed to the various 
buffers, but also control information, e.g., bits that iden- 
tify the kind of data actually to be found in the block. The 5 
identification bits (flags and the like, as will be described 
below) are furnished to the master controller so that it is 
in control of the system at all times. The identification 
bits are used by the demultiplexer to control data distri- 
bution to the various buffers. (The master controller 
issues commands over conductor 76 to the block 
number/pointer analyzer 47 which exercise not only 
general control over this element, but also specific con- 
trol by causing element 47 to turn off the enabling signal 
on conductor 75 as is appropriate to prevent full data 
blocks from entering the demultiplexer if they are not 
required for subsequent processing.) 
[0030] The master controller is at the heart of the sys- 
tem and in fact carries out the bulk of the processing to 
be described below. The user of the player communi- 
cates with the master controller via an interface 79, typ- 
ically a keyboard. The user also is provided with a key 
and lock mechanism, shown symbolically by the 
numeral 81, which is referred to herein as the "parental 
lock" option. If the lock is turned on, then R-rated motion 
pictures will not play. The manner in which this is con- 
trolled by bits actually represented on the disk will be 
described below. If the lock is on, and only an R-rated 
picture is on the disk, a disabling signal on PARENTAL 
LOCK CONTROL conductor 83 closes gate 61 . No data 
bits are transmitted through the gate and the disk can- 
not be played. As will become apparent below, if the 
disk also has on it a version of the film which is not R- 
rated, it will play if it is selected by the viewer. Although 
the parental lock feature is shown as requiring the use 
of an actual key and lock, it is to be understood that the 
feature can be implemented by requiring keyboard 
entries known only to a child's parents. The manner of 
informing the master controller that R-rated versions of 
a motion picture should not be viewed is not restricted to 
any one form. Just as physical keys and coded keys are 
alternatively used to control access to a computer, so 
they can be in the system of FIG. 2. What is important is 
the way in which two different versions can be repre- 
sented on the same disk (without requiring the full ver- 
sion of each), and how the system determines whether 
a selected version may be played in the first place. This 
will be described below. 

[0031 ] Master controller 41 includes several other out- 
puts which have not been described thus far. Conductor 
85 represents a MASTER CLOCK bus which is 
extended to all of the sub-systems shown in FIG. 2. In 
any digital system, a master clock signal is required to 
control the proper phasing of the various circuits. The 
six other outputs of the master controller are extended 
to demultiplexer 63, audio processor decoder 71, pan 
scan processor/vertical scaler 87, video frame store, 
interlace and 3:2 pulldown circuit 89, graphics generator 
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73, and sync generator and DVA converter 92. These 
are control leads for governing the operations of the 
individual circuit blocks. 

[0032] Audio processor decoder 71 processes the 
data in buffers 53 and derives individual audio analog 
signals which are extended to an amplifier/speaker sys- 
tem shown symbolically by the numeral 91. Video 
decoder 67 derives a DIGITAL VIDEO signal on con- 
ductor 93 from the compressed video data which is read 
from buffer 55. The digital video is fed to pan scan proc- 
essor/vertical scaler 87 frame by frame. The particular 
video coding/decoding that is employed is not a feature 
of the present invention. A preferred standard would be 
one along the lines of MPEG1 and MPEG2. but these 
are only illustrative. The same is true of the audio track 
coding. The present invention is not limited to particular 
coding methods. 

[0033] The operations of circuits 57 and 87 can be 
best understood by first considering the symbolic draw- 
ing of FIG. 9. The digital information which is stored on 
the optical disk in the preferred embodiment of the 
invention characterizes frames having a "master" 
aspect ratio of 16:9, the so-called "wide screen" image. 
The master aspect ratio is shown on the upper left in 
FIG. 9. If the ultimate analog signal to be displayed on 
the user's television receiver requires this aspect ratio, 
and the number of horizontal scan lines with picture 
information (as opposed to horizontal scan lines which 
occur during vertical retrace) corresponds with the 
number of horizontal lines represented by the video bit 
information stored on the disk, then the generation of 
the video analog signal is straightforward. But if the tel- 
evision receiver of the user accommodates a TV signal 
having a 4:3 aspect ratio, and the master aspect ratio on 
the disk is 16:9 rather than 4:3, then there are two 
choices. One is to display the original picture in "letter 
box" form. As depicted on the right side of FIG. 9, what 
is done in this case is to vertically compress uniformly a 
master image so that its horizontal dimension fits into 
the confines of the television receiver. This results in the 
vertical dimension being shortened at the same time so 
that it fills less than the full height of the TV display area. 
What this means is that the horizontal line scans at the 
top and bottom of each overall frame must be blanked, 
with dark bands forming in their place — but the original 
aspect ratio is preserved. The other option is for a "pan 
scan" reduced aspect ratio. What this involves is super- 
imposing a box having a 4:3 aspect ratio on the original 
wide screen image. As a result, the left side of the pic- 
ture, the right side, or both sides, are clipped off. (In all 
cases, even if a wide screen image corresponding to a 
16:9 master aspect ratio is to be shown, it may be nec- 
essary to form a number of horizontal line scans which 
is different from the number of horizontal lines repre- 
sented on the disk. The number of horizontal lines is a 
function of the video signal standard to which the video 
output must conform. Changing the number of lines is a 
process known as vertical scaling, as described above.) 
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[0034] With respect to pan scan processing, it will be 
apparent from FIG. 9 that in order to identify that portion 
of a 16:9 master aspect ratio picture which should be 
used to form a pan scan reduced aspect ratio picture, all 
that is required is to specify the starting point along 
each horizontal line scan of the information that should 
be used. Specifying a single number (e.g., column 200 
out of a total of 960 columns) suffices for this purpose. 
The issue, however, is whether the same column is 
always used. In some cases the player may be told that 
if a 4:3 aspect ratio is desired, it should always be taken 
from the middle of the wide screen image. In other 
cases, a variable column starting point may be desired, 
in which case a data block actually contains information 
which represents the starting column number which 
should be used from that point until another change is 
effected. 

[0035] As will become apparent below, the video infor- 
mation in each data block includes a flag which repre- 
sents whether the pan scan column information should 
be updated. If there is such a flag, video decoder 67 
issues a command over conductor 95 to pan scan buffer 
57. At this time the buffer accepts a pan scan update 
from demultiplexer 63. That update remains in the 
buffer, for use by pan scan processor/vertical scaler 87 
with the succeeding frames, until another change takes 
place. 

[0036] It is in pan scan processor/vertical scaler 87 
that the number of horizontal lines is adjusted and the 
aspect ratio is changed. The digital video is furnished by 
video decoder 67 and the pan scan information, if it is 
required, is provided by buffer 57. The output of circuit 
87 consists of uncompressed digital video, in the 
desired aspect ratio and represented by the number of 
horizontal lines required for the selected television 
standard. 

[0037] Once video frame information is stored digitally 
in frame store 89, it can be broken up into interlaced 
fields if the selected standard requires it. Also, 3:2 pull- 
down is the technique used to convert 24-frames-per- 
second motion pictures to 60-fields-per-second video 
(the nominal values of 24 and 60 are in reality 23.97 and 
59.94); to convert data representative of a motion pic- 
ture to an NTSC format, frame information (data blocks) 
must be read at the rate of 24 per second. (As is stand- 
ard in the art, such a transformation applies frame 1 of 
the source material to fields 1 , 2 and 3 of the video sig- 
nal, frame 2 of the source material to fields 4 and 5 of 
the video signal, frame 3 of the source material to fields 
6, 7 and 8, etc., thus yielding 60 fields for 24 original 
frames.) On the other hand, conversion to the PAL 
standard is relatively simple, and 3:2 pulldown is not 
required. The PAL standard requires 50 fields per sec- 
ond. Frames are processed at the rate of 25 per second, 
and every frame is used to form two fields. (Because 
motion picture films are shot at the rate of 24 frames per 
second yet processed at the rate of 25 per second when 
converting to PAL, everything which occurs on the TV 



screen takes place 4% faster in Europe than it does in 
the United States.) Whether the frames are processed 
at the rate of 25 per second or 24 per second is control- 
led by changing the frequency of the MASTER CLOCK 

5 signal on bus 85. 

[0038] The output of block 89 is digital, and is 
extended to sync generator and D/A converter 92. It is 
in this element that appropriate sync pulses are inserted 
into the fields, and the digital information is convened to 

10 analog. Any subtitles that are required are contained in 
buffer 59. Under control of microprocessor 41, com- 
mands are issued over control lead 97 to graphics gen- 
erator 73. This conventional circuit retrieves coded 
character information from the subtitle buffer, and gen- 

is erates a VIDEO signal on conductor 99 which depicts 
the subtitles. The KEY signal is generated on conductor 
98, and the two signals are extended to a conventional 
keyer circuit 96. This device merges the subtitles with 
the video image (utilizing hard or linear keying at the 

20 manufacturer's option, as is known in the art), and 
extends the composite video signal to a conventional 
TV display device 94. 

Lead-in Track Fields 

25 

[0039] Before proceeding with a description of the 
detailed processing, it will be helpful to consider the 
information which is stored in the lead-in portion of the 
disk track. This information is stored in individual fields 

30 as depicted in FIG. 3, and it is this information which 
controls subsequent processing of the data read from 
the disk. The format of a data block is shown in FIG. 4, 
but for an understanding of how the data in this block is 
used, it is necessary to appreciate the set-up informa- 

35 tion which is read first. 

[0040] Referring to FIG. 3, at the start of the track 
there are a number of lead-in sync bits. Although for all 
other entries minimum and maximum numbers of bits 
are depicted in the appropriate columns, no such num- 

40 bers are provided for the lead-in sync bits. The number 
of sync bits required at the beginning of the track 
depends on the hardware employed. Given the particu- 
lar hardware and range of disk speeds involved, a suffi- 
cient number of sync bits are provided at the start of the 

45 track to allow the circuits involved with reading the disk, 
including disk drive controller 27 and block 
number/pointer analyzer 47, to synchronize themselves 
to the bit stream on DATA OUT conductor 25. Bit syn- 
chronization is a technique well known in digital sys- 

so terns. 

[0041 ] The second field consists of 40 bits represent- 
ing authorized territories. There are several ways in 
which software publishers can lock out play of their soft- 
ware. The most important involve controlling whether R- 
55 rated motion pictures can be played (the parental lock 
out option), and whether the final analog output video 
signal can assume the standard selected by the user. It 
is in this way, for example, that a software publisher 
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might allow a motion picture to be played on an NTSC 
receiver but not a PAL receiver. But as long as the player 
is provided with this kind of lock out control, it can be 
extended to territories. All players used with the disks of 
the invention conform to the same set of specifications. 
One feature of the design is that each player is provided 
with a representation of the territory or territories for 
which it has been intended for sale. For example, the 
territory or territories can be represented by the settings 
of a DIP switch, a code stored in a microprocessor ROM 
(e.g., in master controller 41) or the like. It is assumed 
that there are a total of 40 possible territories. Each disk 
has a 40-bit field in its lead-in section, each bit of which 
is associated with one of the 40 territories. A 1 in any bit 
position is an indication that the disk is authorized for 
play in the respective tenitory, and a 0 is an indication 
that it is not. A player whose code indicates that it is for 
sale in China, for example, will not play a disk if there is 
a 0 in the 40-bit territory field at the position associated 
with China. 

[0042] As an example of the use of such a feature, 
consider a player intended for sale in a particular coun- 
try. A software publisher might put out a motion picture 
film which for contractual reasons is not to be released 
in that country. It is for this reason that a 0 would be 
stored in the bit position associated with that country in 
the authorized territories field of the lead-in section of 
the track. Upon sensing this bit, master controller 41 
would cause circuit 47 to generate an inhibit signal on 
conductor 75 which would permanently cause gate 61 
to block all data from passing through it. 
[0043] The third field is a single bit, a flag which indi- 
cates whether there is any information in the following 
field. This information is termed herein "special soft- 
ware." The player of FIG. 2 ordinarily executes the same 
software code, typically contained in read-only memory. 
It is this code which will be described in connection with 
the flowcharts of the drawing. However, since the player 
is microprocessor controlled, there is no reason why it 
cannot be used for some even totally unrelated pur- 
pose, and this can be enabled simply by loading soft- 
ware from the disk If the special software flag is a 1, 
then master controller 41 reads on conductor 77 the 
software which immediate follows in field 4. Thus 
depending on whether the special software flag is a 0 or 
a 1 , the fourth field is either empty or contains software 
of undetermined length. At the end of the software there 
is a sync word which is unique in the sense that this 
word is not allowed to occur anywhere in the overall 
data stream. When the sync word pattern appears, it is 
an indication that the preceding data field has come to 
an end, and a new field follows, (in the event data hav- 
ing the sync word pattern would otherwise appear in the 
data stream and be misinterpreted as a sync word, it 
can be avoided using known techniques. For example, if 
the sync word consists of 32 bits of a predetermined 
pattern, and some overall data sequence includes this 
pattern within it, then after 31 bits of the data pattern are 



recorded, an extra bit, having a value opposite that of 
the last bit in the sync word pattern, may be inserted in 
the bit stream. When the player sees this bit it discards 
it and treats the following bit as a data bit instead of the 

5 last bit of the sync word.) 

[0044] An example of special software might be soft- 
ware for controlling video games. While the player is 
provided with an operating system designed for the play 
of motion pictures and multi-tack audios, it is certainly 

10 feasible for the player to perform additional and/or differ- 
ent functions involved in the play of video games. This is 
especially true if the user interface is detachable and 
joysticks and the like may be connected in place of a 
keyboard to accommodate game-playing peripheral 

is equipment. The system can be convened to a video 
game player simply by storing the necessary software 
as it is read from the disk. While in the flowcharts to be 
described below the special software is shown as being 
self-contained and not involving the standard process- 

20 ing steps, the special software can certainly call operat- 
ing system subroutines for execution in order to take 
advantage of the built-in code. 

[0045] The fifth field consists of 1 2 bit positions, each 
corresponding to a different standard. Standards 

25 include 1250-line European HDTV, 1 125-line Japanese 
HDTV, 1050-line proposed American HDTV (as well as 
1080-line and 787-line proposed standards), 625-line 
PAL, 525-line NTSC, 625-line SECAM, 360-line "letter 
box", etc. it is even possible to accommodate future 

30 standards, although to form an appropriate video signal 
in such a case different software would be required. 
However, that simply entails providing software on a 
disk to supplement the built-in operating system. 
[0046] As a single example, if the first bit position of 

35 the 12-bit field corresponds to the NTSC standard, and 
if the user selects an NTSC standard for play on his TV 
' receiver, or if that is his default setting (as will be dis- 
cussed below), then an NTSC signal will be generated 
only if the first bit in the authorized standards field is a 1 . 

40 [0047] Field 6 always contains 100 bits. These bits 
represent respective audio languages -- dialog -- for a 
motion picture. It is rare that so many foreign-language 
versions of the same motion picture will be prepared, 
and it is not contemplated that so many versions will 

45 actually be included on a disk. In fact, there are a maxi- 
mum of 16 audio tracks which can contain dialog in dif- 
ferent languages. Each of the 100 bits, except the first, 
represents one of 99 languages. If there is a 1 in the 
corresponding bit position, it is an indication that there is 

so an audio track with dialog in the corresponding lan- 
guage. 

[0048] The first of the 1 00 bit positions does not really 
correspond with a language. Instead, a 1 in the first bit 
position means that there is a music and effects ("M&E") 
55 track. (By "effects" is meant such things as the sound 
associated with thunder, gunshots and the like.) As indi- 
cated in the Comments field on FIG. 3, there are N "1 "s 
in field 6 of the lead-in section of the overall track, where 
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N has a maximum value of 1 6 (one M&E track and up to 
1 5 dialog tracks, or up to 1 6 dialog tracks without M&E). 
As a single example, suppose that the third bit position 
corresponds with French, the fifth corresponds with 
Greek, and the 100-bit field is 10101000... .0. This 5 
means that there is an M&E track, as well as French and 
Greek dialog tracks. It does not mean that every single 
data block on the disk includes bit information which 
represents M&E, and French and Greek dialog. What it 
does mean is that any data block has at most three 10 
audio tracks with M&E and/or dialog. It also means that 
any data block which has such audio track information 
contains the information in the order M&E, French, 
Greek. Just how the system determines which specific 
data blocks contain audio information for those Ian- 15 
guages represented in the 1 00-bit field will be described 
below in connection with the fields contained in a data 
block. 

[0049] It should be understood that the language 
audio tracks do not necessarily include just dialog. As 20 
will be described shortly, it is possible to mix an M&E 
track with a French dialog track, with the result being a 
complete audio track suitable for play in France. But it is 
certainly possible that a particular audio track will 
include pre-mixed M&E and original dialog. For exam- 2s 
pie, if bit position 10 of the 100-bit field represents Eng- 
lish dialog and there is a 1 stored there, it means that 
there is an English language version of audio on the 
disk. However, it is possible that in the corresponding 
audio track there is not only English dialog, but a full 30 
sound track including the M&E. At the same time, there 
may be M&E in a separate track, if there is a 1 in the first 
bit position of the 100-bit field. How the various tracks 
are processed in order to derive a complete sound track 
for play in any given language depends on subsequent 35 
information. Field 6 simply represents which audio lan- 
guages are available, as well as whether there is a sep- 
arate M&E track (without any dialog). 
[0050] There is another piece of information which is 
necessary in order for the audio scheme to function, 40 
and that information is represented in field 7. For each 
of the N available audio language tracks (up to a maxi- 
mum of 16), there is a 3-bit code in the seventh field. 
Before describing the meaning of the codes, it must be 
understood how the codes are associated with particu- 45 
lar tracks and languages. Suppose that field 6 is 
101010000100.. .0 which is interpreted to mean that 
there is an M&E track, a French track, a Greek track and 
an English track. From this information alone, there is 
no way to tell whether there is even any M&E in the so 
French, Greek and English tracks. All that is known lan- 
guage-wise is that dialog is available in only three lan- 
guages. For this example, there would be 12 bits in field 
7. The first three bits are associated with the M&E track, 
the second three bits are associated with the French 55 
track, and the third and fourth 3-bit codes are associ- 
ated with the Greek and English tracks respectively. The 
3-bit codes are as follows: 



000 - mixing master (M&E) 

001 - switching master (M&E) 

010 dialog + (M&E), complete audio track 

01 1 « track to be mixed with mixing master 

100 - track to be switched with switching master 

These five codes are all that are necessary to form com- 
plete sound tracks in the three available languages, 
French, Greek and English. How the tracks are com- 
bined will be described below, but what should be borne 
in mind is that the purpose of the entire arrangement is 
to provide sound tracks in many languages (up to 15), 
without requiring what might be a 2-hour audio record- 
ing for each. In fact, if a movie is two hours long, but the 
actual dialog is only 30 minutes, the goal is to record 
one full track (M&E or original sound track), with only a 
30-minute audio recording of dialog for a particular lan- 
guage. 

[0051 ] Field 8 contains Nx4 bits, that is, 4 bits for each 
of the N "1 "s in field 6. There is thus a 4-bit code in field 
8 for each audio language track which is available on 
the disk. The 4-bit code represents the track type, and 
there are a maximum of sixteen possibilities. Typical 
track types are single-channel mono, two-channel 
Dolby, 5.1 -channel Musicam, etc. [The term 5.1-chan- 
nel refers to left, right, center, left rear and right rear 
channels, together with a sub-woofer channel.] The 4- 
bit track type codes allow the master controller to deter- 
mine the manner in which audio processor decoder 71 
operates on the data in the up-to-16 audio tracks to 
derive analog outputs for speaker system 91 . 
[0052] Considering again field 7, there are several 
ways in which a complete sound track, in a selected lan- 
guage, can be derived from the disk. The operation of 
mixing involves mixing (adding together) two sound 
tracks. The operation of switching involves switching 
between two sound tracks, and playing only one of them 
at any given time. The first track is always M&E, if it is 
available. The code for this track is always 000 or 001 . If 
the code is 000, it means that there is no dialog in the 
track and its M&E is to be mixed with the selected lan- 
guage track. If the code 011 is associated with the 
French track, for example, it means that the first and 
third tracks should be mixed at all times. The dialog, 
when there is dialog, appears in the French track, and 
mixing it with the mixing master provides a complete 
French sound track. On the other hand, the first track 
may be a switching master. What this means is that 
music and effects are recorded in this track, with or with- 
out dialog. The French track in this case would be rep- 
resented by a 1 00 code. It contains M&E and dialog, but 
only when there is dialog. The M&E track, the first, is 
played alone when there is no dialog, but the fifth track 
is played alone when there is. The tracks are switched, 
not mixed. The French track, when dialog is recorded in 
it, includes not only dialog but M&E as well since this 
would be the only source of M&E in a switched type 
operation. 
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[0053] The fifth possibility (010) is that a particular 
track happens to contain the original sound track, M&E 
together with dialog in the original language. If the dia- 
log is in the selected language, the track can be played 
from beginning to end, by itself. This track can also 
serve as a switching master (code 001) for other lan- 
guages. 

[0054] When it comes to mixing tracks, whatever 
audios are in the two specified tracks (the mixing master 
and the track which is mixed with it) are simply added 
together at all times; whatever audio there is in the two 
tracks gets played. It is only when switching between 
the switching master and the track with which it is 
switched that one track gets played in lieu of the other. It 
is true that each track may contain audio information 
only when the other does not (which would allow mix- 
ing), but it is conceivable that the switching master will 
also include dialog, i.e., if it is a recording of the original 
sound track of the motion picture. That is why switching 
is employed -- only one track is heard from at any given 
moment. As will be described below, each data block 
includes bits which inform the master controller which 
audio tracks actually contain data in that block. If a 
selected audio language track with an original 100 track 
code has data in any data block, then the audio proces- 
sor decoder 71 processes the data in that audio track to 
the exclusion of any data which might be in the switch- 
ing master track. 

[0055] Field 9 on FIG. 3 contains six bits which are 
coded to represent a number M. This is the number of 
"other" audio tacks, separate and apart from the up-to- 
16 audio language tracks. The usual use for these 
tracks is to represent, in compressed digital form, indi- 
vidual instruments or mixes of instruments, with the 
user having the option of combining them. In an extreme 
form, there could be 63 separate instrumental tacks, 
with the user being able to combine any tracks he 
desires, and to set their relative levels before mixing. If 
one of the tracks contains the combined sound to begin 
with, it is possible to delete an instrument from the 
orchestral mix by specifying that its information content 
should be deleted, or subtracted, from the orchestral 
mix. This would allow a user, for example, to play his 
piano to the accompaniment of an orchestra playing a 
concerto from which piano play has been eliminated. It 
would also allow a user to single out a particular instru- 
ment to facilitate practice. Precisely what the user does 
with the "other" audio tracks is determined by menu 
selections which are made available to him. Field 8 sim- 
ply identifies how many "other" audio tracks are present 
on the disk. (The term "other" audio tracks would 
appear to be rather non-descriptive, but this isn't the 
case. The intent is that the term subsume any audio 
track usage other than the provision of sound tracks for 
motion pictures. Rather than to have orchestral music in 
these "other" audio tracks, for example, it is possible to 
have individual vocalists, allowing a user to study differ- 
ent harmonizations.) 



20 

[0056] It is apparent that if there are indeed 63 "other" 
audio tracks, then much if not most of the disk capacity 
may be allocated to audio data. But that is precisely why 
so many audio tracks are made available. It is certainly 
s contemplated that some disks playable in the system of 
FIG. 2 will not include video. In fact, field 19, to be 
described below, is a 1 -bit field which informs the mas- 
ter controller whether there is any video data at all on 
the disk. 

w [0057] Once it is determined that there are M "other" 
audio tracks, the next field specifies how each track is 
coded. As in the case of field 8, a 4-bit code is used for 
each of the "other" audio tracks. Thus the number of bits 
in field 10 can be as low as 0 (if there are no "other" 

is audio tracks) or as high as 252 (63 x 4). 

[0058] While the player can determine from reading 
fields 9 and 1 0 how many "other" audio tracks there are, 
the user has to be told what is in these tracks in order 
that he know what to do with them. There is a descrip- 

20 tion of each track, and it is in multiple languages. The 
first thing that the player must be given is a list of the 
languages in which there are descriptions of the "other" 
audio tracks. A 100-bit field is used for this purpose. As 
indicated in FIG. 3, field 11 has 100 bits. A 1 in any bit 

25 position is an indication that track definitions are availa- 
ble in the respective language. The correspondence 
between bit positions and languages is the same in field 
11 as it is in field 6. It will be recalled that the first bit 
position in field 6 corresponds to M&E, not a traditional 

30 "language". The first bit position in field 1 1 is thus not 
used, and there can be at most 99 "1"s in field 1 1 . 
[0059] Before the track definitions are actually read 
and processed, the player must determine what menu 
choices to provide the user. Suppose, for example, that 

35 there are ten "other" audio tracks, each having sounds 
of different orchestral instruments. Once the track defi- 
* nitions in the selected language are made available to 
the operating system, it can display a standard menu to 
the user. The user can then pick particular tracks to be 

40 played together, particular tracks to be deleted, their rel- 
ative sound levels, and other "standard" choices. How- 
ever, in case the "other" audio tracks do not represent 
orchestral music, or they do represent it but in a way that 
requires unusual menu selections, the standard operat- 
es ing system software for interfacing with the user so that 
the system can determine what is to be done with the 
"other" audio tracks will not suffice. To accommodate 
unusual situations, the operating system must be pro- 
vided with special software for the creation of the menu, 

so as well as to control how the selected tracks are 
mixed/deleted following user selections. The technique 
used is the same as the technique described above in 
connection with loading special software for changing 
the overall operation of the player (fields 3 and 4). Field 

55 12 is a single bit If it is a 1 , it is an indication that there is 
a field 13 which contains special mixing/deletion soft- 
ware. As indicated on FIG. 3, field 13 thus has any- 
where from no bits to an undetermined number which is 



EP 0 979 007 A2 



11 

BNSDOCID: <EP 0979007A2J_> 



21 

dependent on the length of the special software to be 
loaded into the machine from the disk. The special soft- 
ware ends with a sync word so that the player will know 
when the next field begins. 

[0060] The next field, field 14, consists of the track def- 
initions themselves. Since there are M "other" audio 
tracks, and there are P languages in which they are to 
be defined for the user, PxM character strings are repre- 
sented in field 14. Each string is separated from the next 
by an escape character. First there are M character 
strings (track definitions) in the first language corre- 
sponding to the first position in field 1 1 which contains a 
1 , then there are M character strings in the second lan- 
guage corresponding to the second bit position in field 

1 1 which contains a 1 , etc. As will be described below, 
the user informs the player in which of the available lan- 
guages the menu which includes the track definitions 
should be displayed. While the entire DATA OUT bit 
stream from the disk drive is extended to the master 
controller in the system of FIG. 2, only the character 
strings corresponding to the selected language are 
processed. They are processed and displayed in 
accordance with the standard software, or the special 
mixing/deletion software which was just read from field 

12 if such software is included on the disk. (It should be 
noted that it is the function of demultiplexer 63 to distrib- 
ute to the several buffers only the respective data bits 
that are intended for them. It is controller 41 that tells the 
demultiplexer what to do after the controller interprets 
the information in both the lead-in track section and the 
individual data blocks.) 

[0061] As described in connection with FIG. 2, provi- 
sion is made for the insertion of subtitles. The language 
is selected by the user as will be described, but the 
player must be told the languages in which subtitles are 
available. Another 100-bit field is used for this purpose. 
As indicated in line 15 of FIG. 3, the "1"s in the field rep- 
resent the individual languages available for subtitles. 
As is the case with the available display languages, 
there is a maximum of 99 since the first bit position cor- 
responds to M&E which is not strictly speaking a "lan- 
guage." 

[0062] Field 16 is a 4-bit multiple version code. The 
player is informed not only whether there are two ver- 
sions of the same video presentation on the disk, but 
also what the choices are with respect to them. The first 
bit is a 0 if there is only one version on the disk, in which 
case the second and fourth bits are ignored. Bit 1 has a 
value of 1 if there are two versions on the disk. The sec- 
ond bit in the code tells the player whether the parental 
lock option is to be implemented, or whether a different 
criterion is to be used in selecting which version is 
played. The usual situation is where the parental lock 
option is implemented, in which case the bit in the sec- 
ond position of the 4-bit code is a 0. This informs the 
player that it should determine whether the parental lock 
option is "on." If it is. R-rated (or, more broadly, adult- 
rated) versions should not be played. The bit in position 
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3 of the code is an indication whether version A (the first 
or only version) is R-rated or not (0 = no, 1 = yes), and 
the fourth bit in the code provides the same information 
for version B if there are two versions; if there is only 

5 one version, the fourth bit is ignored. This is all the infor- 
mation the player needs to determine whether either or 
both of two versions can be played. When there are two 
versions of the same motion picture on the disk, the 
user is asked to select one of them. But if the parental 

10 lock option is "on" and one of the two versions is R- 
rated, the user is given only the choice of playing the 
non-adult version, or playing neither, as will be 
described below. If both versions are R-rated and the 
parental lock option is "on", then the user can watch nei- 

15 ther version. 

[0063] On the other hand, it is possible that there will 
be two versions of the same material on the disk, but it 
is not a question of one of them being adult-rated and 
the other not. For example, one version might be a 

20 teaching film including questions and answers, and the 
other might involve a test on the same subject matter 
including just questions. For the most part the two ver- 
sions would be the same. In such a case, the first bit in 
field 16 would still be a 1 to indicate that two versions 

25 are available, but the second bit would now be a 1 
instead of a 0. to indicate that the choice between the 
two versions does not depend on whether they are R- 
rated or not A 1 in the second bit position is an indication 
that the third and fourth bits characterize the two ver- 

30 sions respectively with respect to a characteristic other 
than rating. 

[0064] What the third and fourth bits actually mean in 
this case, and what menu choices are provided the 
user, has to be determined by resorting to different cri- 

35 teria. The same technique that was used twice previ- 
ously is now used once again - special software is 
provided along with the version codes. Field 17 consists 
of a single bit which serves as a flag to indicate whether 
special version software is available. If the bit is a 1 , 

40 then field 18 is read to access the software. As in the 
case of the two earlier software fields, field 18 termi- 
nates with a sync word to indicate the start of the next 
field. The special software controls a menu presentation 
that is unique for the particular disk. 

45 [0065] The next field consists of a single bit As indi- 
cated in FIG. 3, it informs the player whether video data 
is available. If it isn't, it simply means that there are no 
video data block fields in the overall data blocks to be 
described in connection with FIG. 4. 

so [0066] Field 20 is a single bit, and it identifies the base 
or master aspect ratio. If the bit has a value of 0, it is an 
indication that any video on the disk has a 16:9 "wide 
screen" aspect ratio, as depicted in FIG. 9. On the other 
hand, if the bit is a 1 , it is an indication that the aspect 

55 ratio of the video on the disk is 4:3. 

[0067] As described above, if the original video has a 
"wide screen" aspect ratio, then there are two ways in 
which a 4:3 reduced aspect ratio can be derived. One 
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way is to form the video image from the middle part of 
the "wide screen" original. Another way is to "pan scan" 
in the sense that the section of the original image which 
is actually utilized is not necessarily always the middle 
part. In fact, FIG. 9 shows the use of more information 
on the left than on the right of the original image. Field 
21 is a single bit which is indicative of pan scan availa- 
bility. If field 20 is a 1 , the base aspect ratio is 4:3 so that 
pan scan availability is irrelevant -the single bit in field 
21 is simply ignored. But if the base aspect ratio is 16:9 
(field 20 has a 0), the value of the bit in field 21 tells the 
player whether the subsequent data blocks provide 
starting column information which can be loaded into 
pan scan buffer 57 on FIG. 2. If the bit in field 21 is a 0, 
the data blocks do not include column number informa- 
tion, and if the video is to be played in a 4:3 aspect ratio 
from a "wide screen" original, then the video image is 
formed from the middle part of each original frame. On 
the other hand, if pan scan information is available in the 
data blocks, then buffer 57 on FIG. 2 is updated as 
required and the final video formed will have an added 
depee of variability. 

[0068] Field 22 is a 20-bit number which represents 
the total number of data blocks on the disk. However, if 
there are two different versions, while they have many 
data blocks in common, the remaining numbers of 
blocks in the two versions may be different For example, 
a scene might be completely omitted from one of the 
versions, in which case it would have a smaller total 
number of data blocks. For this reason, if field 16 indi- 
cates that there are two versions of a motion picture or 
other source material on the disk, field 23 provides the 
total number of data blocks in version A, and field 24 
provides the total number of data blocks in version B. 
Both fields are omitted if there is only one version on the 
disk. 

[0069] Each data block may include video information 
for a variable number of frames. The system could 
determine the total playing time from the number of data 
blocks (either the total number if there is only a single 
version, or two different numbers if there are two ver- 
sions), only if the system is informed of the original 
frame rate and the average number of frames repre- 
sented in each block for the disk as a whole. Two disks 
with the same number of data blocks will have different 
running times if the original source material for one of 
them was motion picture film whose frames were gener- 
ated at the rate of 24 per second and the other had an 
original source material derived from a 30 frame-per- 
second video camera. Field 25 is a 4-bit value that iden- 
tifies the original frame rate (24, 30, etc.), a number nec- 
essary for proper generation of the video signal. 
Although the time represented by each data block could 
be determined from the frame rate if each data block 
contains only one frame, it is possible to store more or 
less than one frame of data in each data block. Also, 
there may be no frame information at all, i.e., the video 
availability flag in field 19 may be 0. Consequently, field 
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26 is provided. This field contains a 10-bit number which 
represents the block time factor, i.e., the avenge time 
duration represented by each block. Multiplication of the 
block time factor by the total number of blocks (or the 
5 total number in a particular version) yields the running 
time. (In practice, the block time factor is about the same 
for both versions on a disk. If desired, individual block 
time factors can be provided.) 

[0070] As is common practice with optical disks in 

10 general, the disk of the invention may be provided with 
a table of contents for allowing the user to select a par- 
ticular part to play, or simply to inform the user of pre- 
cisely what is on the disk and how long each part takes 
to play. Field 27, if included, is a table of contents. If only 

is one version of the source material is on the disk, then 
there is only one table of contents. Otherwise, there is 
an additional field 28 which consists of the table of con- 
tents for the second version. FIG. 3 sets forth the sub- 
fields in field 27. 

20 [0071 ] For lack of a better term, the video presentation 
is divided up into what are called "chapters.* 1 For each 
chapter the table of contents includes an 8-bit chapter 
number, thus allowing a maximum of 255 individual 
chapters. Following each chapter number there is a 20- 

25 bit starting block serial block number. It will be recalled 
that all of the data blocks on the disk are numbered seri- 
ally. In other words, while data blocks may be common 
to both versions A and B, or unique to only one of them, 
the numbers of the data blocks are in serial order along 

30 the disk track The table of contents includes the serial 
block number of the data block which is the starting 
block for each chapter. 

[0072] Similarly, in order to determine the play time for 
each chapter, the system must know how many blocks 

35 are included in each chapter. For this reason, the next 
piece of information is a 20-bit block duration. Multiply- 
ing this number by the block time factor allows the play 
time of each chapter to be determined. Alternatively, the 
actual running time for each chapter could be provided 

40 instead of the block duration. (Such information could 
be provided for different versions and standards.) 
[0073] In order to display the title of each chapter, lan- 
guage strings must be provided. Once again, the sys- 
tem must be advised of the languages which are 

45 available for displaying chapter titles so that the user 
might select one of them. The usual technique of provid- 
ing a 100-bit block for identifying available languages is 
employed. 

[0074] Finally, the actual language strings for identify- 
so ing individual chapters are provided. Each string ends 
with an escape character to separate it from the next 
string. This is the same technique used in connection 
with the "other" audio track definitions discussed above 
in connection with field 1 4. 
55 [0075] Field 29 has a minimum of 1 00 bits and a max- 
imum of 1200 bits. It will be recalled that there can be up 
to 12 authorized standards, i.e., the final video output 
can be in up to 12 different formats. In order to insure 
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conformance with quality standards agreed upon by all 
manufacturers of players and all software publishers 
who have agreed to support a common set of specifica- 
tions, it is possible to prevent unauthorized software 
publishers from publishing disks which will play on play- 
ers of the invention. Moreover, it is possible to limit par- 
ticular publishers to the manufacture of disks which will 
play according to only a sub-set of the 1 2 standards. For 
example, if royalties are to be paid on each disk which is 
manufactured according to the agreed-upon specifica- 
tions, and the royalties vary in accordance with the 
number of standards according to which a disk can be 
played, it is possible to limit certain software manufac- 
turers to only the sub-set of standards for which they 
have agreed to pay. For this reason, there is an 
encrypted authorization code for each standard; the 
codes are all stored in field 29. The disk will play accord- 
ing to a particular standard only if the proper encrypted 
authorization code is contained on the disk. Field 29 
includes 1 00 bits for each of the standards authorized in 
field 5. Since at least one standard must be authorized 
there are at least 100 bits. The maximum number of bits 
is 1200 if all 12 standards are authorized. 
[0076] The encryption scheme is based upon the prin- 
ciples of public-key cryptography. Public-key cryptogra- 
phy is by now well known, and a particularly clear 
exposition of the subject is to be found in the August 
1979 issue of Scientific American, in an article by Hell- 
man entitled "The Mathematics of Public-Key Cryptog- 
raphy." The use of a public-key cryptosystem allows a 
message to be encrypted at site A in accordance with a 
secret key, transmitted to site B, and decrypted at site B 
in accordance with a public key. The secret key for 
encrypting the message is known only to the transmit- 
ter. Such a scheme is typically used to authenticate a 
message. Upon decryption of the transmitted encrypted 
message at the receiving site, the message will be intel- 
ligible only if it was encrypted with the paired private 
key. And since the private key is private, if the decrypted 
message is intelligible, it must have originated with the 
owner of the private key. 

[0077] Public-key cryptography is used in the inven- 
tion in the following way. The actual data on the track is 
processed by the software publisher in accordance with 
a predetermined algorithm. The details of the process- 
ing are not important. Any non -trivial processing that 
provides, for example, a 100-bit result based on the disk 
data will suffice. The 100-bit result is a "message" to be 
transmitted via the disk in anywhere from one to twelve 
encrypted forms. There are 12 cryptosystem key pairs, 
each associated with a different one of the standards. 
The private key for the first standard authorized on the 
disk is used to encrypt the 100 -bit message and the 
100-bit encryption is stored in field 29. This encryption 
is the authorization code for the particular standard. The 
same thing is done for all of the other standards author- 
ized for the particular disk, with the private key associ- 
ated with each of these standards being used in each 



case. 

[0078] The player operating system computes the 
same 1 00-bit result or message that was originally com- 
puted by the software publisher. The player software 

s then uses the public key associated with each of the 
standards authorized on the disk to decrypt the respec- 
tive encrypted authorization code for that standard. The 
decrypted message should match the message com- 
puted by the operating system after processing the disk 

10 data. If they do not match, it is an indication that the soft- 
ware publisher did not have the private key for encrypt- 
ing the authorization code for the particular standard, 
and the player will not produce a video signal according 
to that standard. 

is [0079] To explain this in another way, let it be assumed 
that the private key for authorized standard N on the 
disk gives rise to an encrypted message Pri N (X), where 
X is a message to be encrypted. Similarly, the function 
Pub N (X) represents the decryption of a function X using 

20 a paired public key. Let it further be assumed that the 
predetermined algorithm for processing the data on the 
disk is known by all player manufacturers and software 
publishers, and gives rise to a 100-bit result which is 
treated as a "message" M whose content (value) 

25 depends on the disk data. For standard N, the software 
publisher, after first deriving M, stores on the disk the 
100-bit encrypted authorization code Pri N (M). The 
player first derives the value M in the same way that the 
software publisher did. The player software then uses 

30 the public key associated with standard N for decrypting 
the encrypted authorization code. The operating system 
thus derives Pub N (Pri N (M)). Since decryption of an 
encrypted message should result in the original mes- 
sage, the result of this decryption should be the same 

35 value M which the operating system derives by process- 
ing the disk data. If it is, then the particular standard is 
not only authorized, but the publisher has the right to 
authorize it. On the other hand, if the decryption of the 
encrypted authorization code M does not match the 

40 algorithmic result M derived by the player (because the 
software publisher did not have the private key with 
which to derive Pri N (M)), then that particular standard is 
locked out. 

[0080] While such a scheme works in the abstract, 
45 there is one practical problem which must be overcome. 
Suppose, for example, that the algorithm used to derive 
the original "message" M involves processing 20 data 
blocks on the disk with predetermined serial block num- 
bers. (The processing might be something as simple as 
so multiplying by each other successive groups of 100 bits 
each, and using as the result of each multiplication -- for 
the next multiplication -- only the 100 least significant 
bits.) A publisher who is not empowered to authorize 
standard N on a disk may nevertheless wish to do so. 
55 He does not know the private key with which to encrypt 
the derived value M which is applicable to his software. 
Consequently, he does not know what 100-bit 
encrypted code he should put on the disk which will 
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decrypt in a player to the value M. But what he can do is 
copy the 20 predetermined data blocks from some other 
legitimate disk and put them on his own disk, and also 
copy the encrypted authorization code infield 29. Those 
20 data blocks, when processed in a player, will result in 
the value M, and it will match the "stolen" encrypted 
authorization code after it is decrypted in the player. Of 
course, the software publisher may have committed 
copyright infringement, but that simply compounds the 
felony. The practical problem which the software pub- 
lisher faces is that he will have data blocks which are 
"played" and which will be totally out of context insofar 
as his motion picture is concerned. However, because 
the way that multiple versions of a motion picture can be 
stored on the same disk in the first place is that the 
player can be controlled to skip over the play of certain 
data blocks, as will be described below, the software 
publisher can encode his other data blocks so that the 
copied data blocks are not played. In this way, the 
encryption protection can be rendered ineffective. 
[0081] The solution is that while the algorithm that 
derives the "message" M in the first place may also 
operate on predetermined data blocks, it should operate 
on at least the lead-in section of the track. There is no 
way that an unauthorized publisher can copy the lead-in 
track fields from another disk because that would give a 
player incorrect information about the video and audio 
contents on the unauthorized publisher's disk. The lead- 
in data is a function of the particular subject matter of 
the disk, and it must appear in the track in order for the 
disk to play properly. Thus the information represented 
on FIG. 3 can be treated as the "message" M whose 
encryptions, one for each authorized standard, are 
derived using respective private keys and are stored in 
lead-in field 29. (Strictly speaking, the "message" M is 
the result of processing all fields except field 29. Also, 
the longer fields, such as those containing software, can 
be omitted from the processing.) The player derives the 
same "message", decrypts an encrypted authorization 
code with the public key associated with the respective 
standard, and then compares the two. If they don't 
match, the player determines that that particular stand- 
ard has not been authorized for the particular disk's 
publisher. 

[0082] The encrypted authorization code field is 
shown toward the end of FIG. 3 and thus the corre- 
sponding processing is depicted toward the end of the 
flowchart of FIGS. 5A-5C to be discussed below. The 
positioning of the encrypted authorization code field as 
shown facilitates a description of its processing, but in 
fact the field may advantageously be placed at the start 
of the processing. It will be recalled that special soft- 
ware may be read from the disk to modify the normal 
player sequencing. It is therefore conceivable that a 
counterfeiter could write special software which causes 
the authorization code processing to be bypassed. By 
doing the processing before any special software is 
even read, the processing cannot be bypassed. 
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[0083] Returning to a description of the lead-in track 
fields, field 30 is a 1 -bit data block command/data flag. 
This bit informs the operating system whether the data 
blocks include command information or data which is to 

s be read during play of the disk. How The system deter- 
mines whether a particular data block contains com- 
mands or data will be explained below. Field 30 simply 
indicates whether there is any such information at all. 
Finally, fields 31 and 32 are catch-all fields for allowing 

w the disk to control unusual ways in which the player 
processes the information on the disk. It will be recalled 
that field 3 contains a flag which indicates whether field 
4 contains special software which causes the player to 
operate in accordance with a program that is totally dif- 

is ferent from that usually employed, field 12 indicates 
whether field 13 contains special mixing/deletion soft- 
ware for use with the "other" audio tracks, and field 17 
contains a flag which indicates whether field 18 contains 
special version software for processing the 4-bit multiple 

20 version code. Field 31 indicates whether there is "sup- 
plemental" software in field 32. The supplemental soft- 
ware is different from the special software of field 4 in 
that the software in field 4 is basically a substitute for the 
processing which is normally used, while the supple- 

25 mental software generally works with that code, in con- 
junction with commands and data which are to be found 
in the data blocks. 

[0084] Typically, the supplemental software would 
allow play of a video game, with related commands and 

30 data in the data blocks determining the course of play. 
But there are other uses of this technique. As another 
example of the way in which supplemental software, 
and commands and data in the data blocks, can be 
used, consider a disk designed to play a classic motion 

35 picture with subtitles, but which is also provided with a 
critical commentary which is to be displayed periodically 
in lieu of subtitles, perhaps during moments when the 
screen is caused to go blank except for the critical com- 
mentary. To show the flexibility which is possible, let us 

40 even consider a case where the critical commentary is 
to be in a different language. What is required in such a 
case is that the subtitle buffer 59 on FIG. 2 be loaded 
during the play of some data blocks with subtitles in one 
language and with subtitles in another language during 

45 play of other data blocks (some data blocks thus con- 
taining subtitles corresponding to the original motion 
picture, and others containing critical commentary in 
another language). In such a case, the system must 
somehow be told to switch back and forth between lan- 

so guage subtitles, i.e., different subtitle tracks have to be 
processed in different data blocks. This can be conven- 
iently controlled by issuing commands in the data blocks 
themselves. Similarly, if it is desired to blank the screen 
and interrupt the picture during display of commentary, 

55 a data block might include a data value which repre- 
sents the duration of the blanking. Alternatively, if a 
commentary is to be made in a different language, it 
could be a different audio track which is selected for the 
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purpose. In any case, the special software loaded from 
field 32 would control the processing of the commands 
and data contained in the data blocks, and would work 
in conjunction with the operating system of the player. 

5 

Processing Of The Lead-in Track Fields 

[0085] The flowchart of FIGS. 5A-5E depicts the 
processing of the information in the lead-in track fields. 
A description of this preliminary processing is presented io 
at this point, with the functions of the individual fields in 
mind. The fields in the data blocks, as well as process- 
ing of the data blocks, are discussed below. 
[0086] The system processing begins, as shown at 
the top of FIG. 5A, with the reading of default settings. 15 
These are settings established by DIP switches, ROM 
codes, or the use of any other device or technique which 
configures the system on power-up. It is typical in micro- 
processor-based systems to reset all flags and to read 
default settings when power is first turned on. 20 
[0087] There are four default settings which are thus 
determined in order to configure the system. The first is 
the standard - players sold in the United States, for 
example, will typically be configured, in the default state, 
to produce an NTSC video signal 25 
[0088] The next default setting is language - the 
sound track dialog language, the subtitle language (if 
any), and the language in which menus are to be pre- 
sented on the display. In the United States, for example, 
the default language would be English. If the user does 30 
not inform the player that a language other than English 
is desired for one or more of these fractions, audio lan- 
guage track 1 0 will be used to generate the sound track, 
and character strings in the English language will be 
used in setting up the mixing/deletion menu for the 35 
"other" audio tracks and for the table of contents. As for 
subtitles, the usual default is M no language." 
[0089] The third default is the aspect ratio, 4:3 in the 
United States. The aspect ratio determines the relative 
dimensions of the display represented by the final video 40 
output signal. 

[0090] Finally, the parental lock status is determined. 
In the system of FIG. 2, this simply entails a determina- 
tion of the setting of lock 81 . But it is also possible to dis- 
pense with a physical lock and key, and to store the 45 
parental lock status in non -volatile memory after first 
inputting on the keyboard a password known only to the 
persons who exercise control over the lock function. 
[0091] As in many consumer electronic devices, the 
keyboard can be used by the user at any time to interro- so 
gate or control the player. Routine control sequences 
which are standard in the art are not shown in the flow- 
charts. For example, the keyboard, or an associated 
remote control device, can be used to control the vol- 
ume, fast forward, a jump to a specified chapter, etc. 55 
The normal processing can be interrupted to control a 
display by operating a menu key, as is known in the art. 
At the start of the processing of FIG. 5A there is shown 
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a test for determining whether the menu key is oper- 
ated. The reason for showing an interrogation of 
whether the menu key is operated at the start of the 
processing, as opposed to any other time during play of 
the disk, is that this is the mechanism by which default 
settings can be changed. If the menu key is operated 
when power is first turned on, the system displays a 
menu. As indicated in the flowchart, the user is given 
the choice of changing defaults, viewing the table of 
contents for the disk, and/or (in case the menu key was 
operated accidentally) simply returning to the process- 
ing without changing anything. As indicated, depending 
on the menu selection, the defaults are changed, the 
entire menu selection process is aborted, or a TOC 
(table of contents) flag is set to 1 . This flag will be exam- 
ined later to determine whether the table of contents 
should be displayed. 

[0092] Thus far, no information from the disk has been 
processed. (In this description, references are some- 
times made to reading a field and sometimes made to 
processing a field. It is to be understood that even when 
it is said that after a certain processing step a field is 
read, the field may actually have been read earlier but 
stored in a buffer for later use. Depending on the con- 
text, reading a field means to actually read it so that the 
bits appear on the DATA OUT conductor 25 in FIG. 2, or 
to do something with the data if it has been read earlier 
and buffered.) Referring to FIG. 3. the first information 
field which is read from the lead-in track section is a 40- 
bit field representing authorized territories. Next, a 
check is made to see whether the territory in which the 
player was intended for use is one of those authorized 
on the disk. The player territory is also a kind of default 
setting, but it is not grouped with the others because it 
cannot be changed by the user. (To allow a purchaser 
who moves from one territory to another to use his 
player, the player territory can be changed by an author- 
ized technician.) If the player has been designed for use 
in China, for example, and China is not one of the terri- 
tories authorized on the disk, play of the disk is aborted. 
[0093] On the other hand, if the disk has been author- 
ized for play in the player territory, field 3 is read. This 
single bit simply tells the system whether special soft- 
ware is present As shown in the flowchart, if it is present 
then the special software is read from field 4 and exe- 
cuted. The processing terminates with the "execute 
special software" step. This is intended to show that the 
special software in field 4 basically replaces the built-in 
operating system. Such software will be employed when 
a radical change in the overall use of the player is 
involved. (As mentioned above, this is not to say that the 
special software may not call BIOS routines and the like 
from the ROM chips containing the operating system.) 
[0094] If there is no special software present, the sys- 
tem reads the default standard, e.g., it determines that 
an NTSC standard is to be employed. If the user has 
changed the default standard through a menu selection, 
e.g., to PAL, then PAL is the new default standard. The 
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system then accesses field 5 which authorizes up to 12 
standards. The test which is performed is to determine 
whether the default standard (the original, or as 
changed at the start of the processing) is authorized. If 
it is not, a menu is displayed which shows the user the 5 
authorized standards, and he then selects one. After an 
appropriate selection is made, or if the delault standard 
is authorized, the system processes fields 6 and 7. The 
reading of field 6 informs the player of the available 
audio languages (up to 16, including M&E and 15 Ian- 70 
guages). 

[0095] Once again, a default value is tested against a 
set of allowed options. Earlier, it was the default stand- 
ard that was tested against the authorized standards 
read from the disk. This time it is the default audio Ian- 15 
guage (either the default language on power-up or a dif- 
ferent language selected by the user if the menu key 
was operated) that is compared with all of those availa- 
ble. As shown in the flowchart, if the default language is 
not available, a display is formed which lists the availa- 20 
ble audio languages, and the user selects one of them. 
The system then reads the track types in field 7. This is 
the field which informs the operating system whether 
there is an M&E track, whether it is to be used as a mix- 
ing or a switching master, and whether the selected Ian- 25 
guage track is a complete audio track, is to be mixed 
with the mixing master, or to be switched with the 
switching master. Next, the track codings are read from 
field 8. Given the selected language, and its track type 
and track coding, as well as information about M&E, 30 
mixing and switching, the operating system has all of 
the information it needs to generate a sound track for 
the accompanying motion picture which meets the 
needs of the viewer. 

[0096] The next thing that is done is to read field 9 to 35 
determine the number of "other" audio tracks which are 
on the disk, anywhere from none up to 63. If there are 
indeed no "other" audio tracks, all of the processing to 
determine what is to be done with them is bypassed. 
But if there are such tracks, field 1 0 is first read to deter- 40 
mine how they are coded. Since the user has to be told 
what is in the tracks before he can determine what is to 
be done with them, the system must next determine 
from reading field 1 1 the "other" track menu languages 
which are on the disk. The usual type of check is then 45 
made to see whether the menu is available in the default 
language. If it is not, the available languages are dis- 
played and the user selects one of them. 
[0097] As described above, the operating system may 
execute a standard routine for reading the menu, dis- so 
playing it, and interacting with the user as the user 
determines what should be done with the "other" audio 
tracks. But in the event special mixing or deletion is to 
be accomplished, special mixing/deletion software is 
required. Field 1 2 is read to see whether such software 55 
is available and, as indicated in the flowchart, any spe- 
cial mixing/deletion software which is on the disk is read 
from field 13. Only then are the actual menu items (in 
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the selected language) read from field 1 4 and displayed 
for the user. Using the menus made available by the 
operating system, the user selects the play mode for the 
"other" audio tracks. He can, for example, mix them in 
any allowed way, use what is in a track for deletion (by 
phase inversion) from another more inclusive track, 
adjust one track for exclusive play, adjust relative audio 
levels, etc.. The special mixing/deletion software, of 
course, can provide these options as well as others not 
routinely offered. 

[0098] As shown in FIG. 5B, subtitle information is 
now processed according to the established pattern. 
First, the system determines whether subtitles are 
desired at all. At the very beginning of the processing in 
FIG. 5A it will be recalled that one of the default settings 
is the subtitle language. The usual default setting will be 
that subtitles are not desired. If that is in fact the case, 
the subtitle processing is skipped entirely. But if subti- 
tles are desired, the available subtitle languages are 
read from field 15. A test is then made to see if the 
default subtitle language is available. If it is not the avail- 
able subtitle languages are displayed and the user 
selects one of them. 

[0099] Next, the 4-bit multiple version code in field 16 
is read. The first bit indicates whether there are two ver- 
sions available, or only one. A branch is not made at this 
point because first the system must determine whether 
special version software is available, and this is deter- 
mined from field 1 7. If special version software is avail- 
able, it is read from field 18 and executed. To the extent 
that this software must know whether multiple versions 
are available, and what the codes in the third and fourth 
bit positions represent, that has already been deter- 
mined. Although indicated in the flowchart that the 
choices displayed for the user are to select among 
authorized versions, or to exit, it is to be understood that 
the display choices will generally be different if special 
version software is executed. Also, it should be under- 
stood that there may be special version software even if 
there is only one version that can be played. For exam- 
ple, it may be appropriate to warn a viewer that a partic- 
ular program may be extraordinarily unsettling, and to 
ask for a "continue" response before play begins all of 
this being separate and apart from an R-rating. 
[01 00] If special version software is not available, then 
bits 3 and 4 in the 4-bit multiple version code field are 
used for rating purposes. A test is performed to see 
whether the parental lock is on. If it is not, then there are 
no restrictions on the play of versions A and B, and both 
versions are authorized. If it was previously determined 
that there is only one version, then that version is con- 
sidered to be version A and it is authorized. 
[0101] On the other hand, if the parental lock is on, 
tests must be performed to see whether the versions on 
the disk are R-rated. As shown in FIG. 5C, if version A 
is R-rated, and so is version B, then play of the system 
is aborted; although not shown, an appropriate mes- 
sage may be displayed to advise the user why play has 
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stopped. If version A is R-rated but version B is not, then 
only version B is authorized. On the other hand, if ver- 
sion A is not R-rated but version B is, only version A is 
authorized. Finally, even if the parental lock is on, if nei- 
ther version is R-rated, then both versions are author- 
ized. 

[0102] The system next displays the choices available 
to the user. He can choose from among the authorized 
versions, or he can exit and stop playing the disk. (This 
latter case might arise, for example, if a child tries to 
watch an R-rated version, is told that it cannot be 
played, and a decision is made to go on to something 
else more interesting.) 

[0103] If there is only one version available, if it is not 
R-rated, and if there is no special version software, then 
there may be no need for a display - there is only one 
motion picture which can be played, and there are no 
restrictions on who can watch it. Nevertheless, as 
shown in the flowchart, the user is still given a choice 
between play of the disk and aborting play. The system 
could be designed to skip the display in such a case and 
simply to assume that the user wants to watch the only 
motion picture version which is on the disk. On the other 
hand, generating the display allows the user to verify 
that the disk he put in the player is indeed the disk he 
wants. 

[0104] Although the invention has been described 
thus far in terms of one or two versions of a motion pic- 
ture on a disk, it is to be understood that there can be 
three or more versions. This is one of the main reasons 
for providing the capability of reading special version 
software in the first place. This software can include all 
of the information required about the several versions 
from which menu displays are formed so that the user 
can select what is to be played. As mentioned above, 
the special version software can allow choices between 
teaching and test modes, and other options having 
nothing to do with whether particular motion pictures 
are adult-rated. 

[0105] The system next reads the video availability bit 
in field 1 1 , and thus determines whether the data blocks 
which will be processed subsequently contain video 
data. If video data is present, then the base or master 
aspect ratio in which it has been stored on the disk must 
be determined. The next step thus involves reading field 
20 to ascertain whether the base or master aspect ratio 
is 16:9 or 4:3. If the master aspect ratio is 4:3, the next 
five steps are skipped because pan scan availability is 
irrelevant. If the default aspect ratio is 4:3, then there is 
a one-to-one correspondence between stored and dis- 
played frames; if the default aspect ratio is 16:9, then a 
4:3 frame is displayed on a wide screen with a dark 
band at either side. (Alternatively, the 4:3 image could 
be expanded to fill the 16:9 screen, with resulting loss of 
top and/or bottom information.) But if the base aspect 
ratio is 1 6:9, as shown on FIG. 9, there are several pos- 
sibilities which must be explored. 
[0106] One of the default values which is determined 



at the very start of the processing is the aspect ratio. 
The operating system checks whether the default 
aspect ratio is pan scan 4:3. Referring to FIG. 9, if the 
master aspect ratio is "wide screen" (the flowchart 

5 branch being processed), then the possibilities are letter 
box, pan scan centered on the wide screen image (not 
shown in FIG. 9), or pan scan variable (i.e., with a vari- 
able starting column number). If the default is not pan 
scan 4:3, then there are no choices to be made by the 

w user now. The default is either wide screen or letter box, 
and subsequent processing is in accordance with the 
default which has already been determined. 
[0107] On the other hand, if the default is pan scan 
4:3, the issue is whether variable pan scan information 

15 is on the disk. The pan scan availability bit in field 21 is 
read. If pan scan is available, it means that the data 
blocks will specify to the operating system the starting 
column numbers for the pan scan -- the user need 
select nothing at this point. On the other hand, if pan 

20 scan is not available, and this was the user's default, he 
must decide from among two possibilities -- a center 
cut, in which the middle part of every wide screen frame 
is displayed, or a letter box form in which the entirety of 
every frame can be seen, but the display has dark 

25 bands at the top and bottom. A menu display is formed, 
and the user selects one of the two modes. 
[01 08] This use of a common aspect ratio on the disk 
which nevertheless allows the user to select from many 
different kinds of display exemplifies the design 

30 approach of the invention. The basic idea is to provide 
maximum flexibility while nevertheless storing all of the 
required data on an optical disk roughly the size of a 
conventional CD. Once a wide screen motion picture is 
stored on the disk, almost no additional real estate is 

35 required to allow the user to generate a video output 
having some other aspect ratio. Although there may be 
up to 15 languages in which dialog can be heard, there 
are nowhere near 15 full sound tracks because of the 
mixing and switching capabilities built into the player 

40 and the manner in which redundant information is elim- 
inated from the audio language tracks. The same thing 
applies to video standards. While up to now high-quality 
video has required a medium which can be played only 
in NTSC, or PAL, etc., the present invention allows the 

45 same disk to give rise to video signals in up to 12 stand- 
ards. One of the advantages of the invention is that it 
greatly reduces the number of different disks that must 
be produced, for example, by a motion picture company 
that distributes its movies throughout the world. While it 

so is true that some fields may have to be changed from 
time to time, for example, different standards have to be 
authorized when videos are released in NTSC and in 
PAL at different times, such changes are relatively trivial 
and are easily made. 

55 [01 09] Once a decision on the display mode is made, 
field 22 is read to determine the total number of data 
blocks on the disk. If there are multiple versions, fields 
23 and 24 are also read in order to determine the total 
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number of data blocks in each ol the versions. Field 25 
is then read to determine the original frame rate, and 
field 26 is read to determine the block time factor. 
[0110] Field 27 is then processed. It will be recalled 
from FIG. 3 that this is the field that contains all of the 
necessary information for display of the table of con- 
tents. The table of contents for the selected version 
(field 27 if there is only one version, or there are two and 
the first has been selected; or field 28 if there are two 
versions and the second has been selected) includes a 
100-bit representation of the available chapter display 
languages. The default menu language is checked 
against those which are available. If the default menu 
language is not available, the user is informed of those 
languages in which chapter titles can be displayed, and 
he selects from among them. Once it has been deter- 
mined in which language to display chapter information, 
the various table of contents time durations are calcu- 
lated. Since it is known how many blocks are in each 
chapter, the duration of each chapter can be deter- 
mined by multiplying the number of blocks by the block 
time factor. 

[01 1 1 ] The table of contents is not necessarily dis- 
played. It is displayed only if the TOC flag was set at the 
start of the processing, the user having indicated that 
the table of contents should be displayed. If the TOC 
flag is 0. there is no need to display the table of con- 
tents. The system automatically selects the first data 
block as the starting point, that is, play of the disk starts 
at the beginning. On the other hand, if the TOC flag is a 
1, the table of contents is displayed and the user is 
given the option of selecting the start point. 
[01 1 2] Following the table or tables of contents on the 
disk are the encrypted authorization codes for the 
standards authorized in field 5. The operating system 
reads the encrypted authorization code for the standard 
which has been selected. It then reads the predeter- 
mined data for the selected standard. It will be recalled 
that for each of the 12 possible standards, predeter- 
mined data on the disk is processed to derive a "mes- 
sage" M which serves as an authorization code. It is this 
authorization code that is stored in encrypted form on 
the disk using the private key associated with each 
standard. The data which is read from the disk may be 
different for each standard, as long as the same data is 
read and processed both during the encryption process 
and when the player derives the "message" M on its 
own. As discussed above, it is preferred that the data 
include at least part of the lead-in fields because it 
would be self-defeating for an authorized publisher to 
copy this data. 

[01 1 3] After the predetermined data for the selected 
standard is read, the authorization code ("message" M) 
is computed from the data. Using the public key associ- 
ated with the selected standard, which key is built into 
the operating system, the stored authorization code on 
the disk for the selected standard is decrypted. The test 
for whether the software publisher has been authorized 
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to publish disks which will play as video signals in the 
selected standard involves comparing the decrypted 
authorization code with the computed authorization 
code. If they do not match, play is aborted. 

5 [01 1 4] If the two codes do match, field 30 is read. This 
single bit simply informs the master processor whether 
there are any commands or data stored in the data 
blocks other than the normal complement depicted in 
FIG. 4 to be discussed below. If the flag is a 0, the oper- 

10 ating system does not even look for such additional 
commands or data in the data blocks. If the flag is a 1 . it 
means that commands or data may be present in a data 
block, but not necessarily so. 

[0115] Finally, field 31 is read in order to determine 
15 whether supplemental software is available. If it is, it is 
read from field 32. The supplemental software, as 
described above, is not to be used in lieu of the operat- 
ing system software, but rather as a supplement to it. 
This is the basic difference between the software in 
20 fields 4 and 32. Generally speaking, the supplemental 
software operates on commands and data included in 
the data blocks in a field whose presence is indicated 
(although not necessarily in every data block, as will 
become apparent below) by the supplemental software 
25 flag. 

[0116] With the reading of field 32 and its integration 
with the operating system, the read head in the disk 
drive is caused to move to the start point. As described 
above, the start point is either the first data block or a 

30 data block determined by the user if a chapter other 
than the first has been selected. Data blocks are read in 
sequence and demultiplexer 63 on FIG. 2 distributes the 
data fields to various buffers. As indicated in the flow- 
chart, the reading of a data block takes place only if no 

35 buffer is full. Furthermore, before a new data block is 
read, the system checks whether there are any inter- 
rupts which must be serviced. Controller 41 is the 
source of all interrupts. For example, if the user has 
operated the keyboard, the controller generates an 

40 interrupt on line 43 of FIG, 2 which temporarily halts the 
reading of data blocks. After the interrupt has been 
processed, or if there is no interrupt which must be serv- 
iced, the next data block is read. As will be described, 
the serial block number is one of the first things that is 

45 read. The block number/pointer analyzer 47 knows the 
number of the next block which is required. Very often, 
this will simply be the next block in the serial sequence. 
However, the block number may be out of sequence, for 
example, if a jump is to be made to a new chapter, or, as 

so will become apparent below, certain blocks have to be 
skipped on a disk when playing one of multiple versions 
of a motion picture. In any event, the systems checks 
whether the block being read is the correct one. If it is 
not, a branch is made back to the start of the block read- 

55 ing process so that a different block can be read. Also, 
gate 61 on FIG. 2 is closed so that the "wrong" data on 
conductor 25 is not extended to demultiplexer 63. 
[0117] If the block read is the required blocK one of 
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the first things read immediately after the block number 
is pointer data. The pointer data is used by block 
number/pointer analyzer 47 to determine the block 
number of the next data block that is required, as indi- 
cated toward the end of the flowchart. This block 5 
number is transmitted over cable 49 to microprocessor 
disk drive controller 27 in order that it access this data 
block at the completion of the reading of the current 
data block. As indicated at the end of the flowchart, the 
remainder of the data block which is being processed at w 
the moment is read and loaded into the several buffers, 
following which another data block may be read. 
[0118] The flowchart just reviewed controls the 
processing of the player. What is actually done with the 
data read from the data blacks is shown in the flowchart is 
of FIG. 6, and this flowchart will be described after the 
fields in a data block, as listed in FIG. 4, are understood. 
But in order to appreciate the function of the pointer 
data which is included in a data block, FIGS. 7A and 7B 
will be described first. These figures depict how data so 
blocks associated with individual or both versions of a 
motion picture interrelate with each other, and how the 
system is controlled to skip over certain data blocks in 
order to play a selected version. 

25 

FIGS. 7A And 7B - The Function Of The Pointer Data 

[01 19] In the illustrative embodiment of the invention, 
there can be two versions of the same motion picture on 
a disk. Most of the data blocks will represent video and 30 
audio which are common to the two versions. However, 
there will be other blocks that are unique to one version 
or the other. The question is how to control the reading 
in succession of the data blocks that are required for a 
selected one of the two versions. 35 
[0120] For purposes of description, the letters A, B 
and C will be used to identify respectively data blocks 
that are unique to version A of the motion picture, data 
blocks that are unique to version B, and data blocks that 
are common to both. FIG. 7B illustrates a portion of the 40 
track with successive data blocks being labelled A, B or 
C. It will be understood that in practice there may be 
thousands of data blocks in succession of the same 
type, with most of the data blocks on the disk being of 
type C. However, to illustrate the way in which the sys- 45 
tern jumps over data blocks that are not required, FIG. 
7B shows at most two blocks of the same type in suc- 
cession. 

[0121] There are two sequences shown in FIG. 7B, 
one at the top for playing version B, and the other at the so 
bottom for playing version A. If it is version B that is 
selected, and it is assumed that somehow the B block 
on the left is being played, it is apparent that the next 
two A blocks must be jumped over in order to go to the 
fourth block, a B block. After this block is played, the ss 
next A block must be jumped over. Two common C 
blocks are then played, after which a jump must be 
made over an A block to another C. The next block, a B, 



is then played, followed by B, C and B blocks. Finally, a 
jump is made over an A block to the last block shown in 
FIG. 7B, a C block. 

[01 22] If version A is being played, on the other hand, 
two successive A blocks are played, there is then a jump 
over a B block, the next five blocks A, C, C, A, C are 
played, there is next a jump over two B blocks to a C 
block, and finally there is a jump over another B block to 
an A and a following C. 

[0123] The pattern which emerges is that there are 
three kinds of transitions from one block to another. 
First, there is the play of a block immediately following 
play of the preceding block. There are seven examples 
of this shown in FIG. 7B -- AA, BB, CC, CA, CB, AC and 
BC. The two possibilities which are excluded are AB 
and BA, since blocks unique to the two versions will 
never be played during the same disk playing, much 
less one after the other. While there are seven kinds of 
transitions from block type to block type, there are really 
just three basic operations - going from one block of 
any type to the next block of any type; a jump from either 
an A to an A or C, or from a B to a B or C; or a branch 
from a C block either to an adjacent A or B, or to a B or 
A somewhere down the line. Most transitions are of the 
first type. The second type occurs when an A is followed 
by a B (which two blocks can never be played in succes- 
sion); a jump must be made from the A to either another 
A or to a C. Similar remarks apply to a B followed by an 
A. The third type occurs at the end of the play of a C 
block, when there is no longer any common material to 
be played and a switch must be made to one version or 
the other, the next block is played if it is part of the ver- 
sion selected, or some blocks will have to be jumped 
over if the branch is to a block in the other version. 
[01 24] FIG. 7A shows the state diagram which defines 
how and when transitions are made from one block to 
another. As will be described below, every data block 
includes a two-bit pointer flag, possibly followed by a 
field which contains a 20-bit pointer. (When a pointer is 
present, it always points to the serial block number of 
another data block.) Referring to the code given in FIG. 
74 if the two-bit pointer flag is 00, it is an indication that 
the processing should continue with the next block; in 
this case, there is no need for a pointer. If the two-bit 
pointer flag is a 01 code, it is an indication that a jump 
should be made to a block in the same version some 
distance away, or to a C block some distance away. In 
either case, a pointer is necessary. 
[0125] The codes 10 and 1 1 are used when a branch 
is to be taken from a common C block. Which code is 
used depends on whether the next block is an A or B. If 
the block after the C is an A, code 10 is used and the 
pointer is to a B or a C further down the line, If the code 
is 1 1 , it means that the next block is a B, and the pointer 
is to an A or a C further along the track. The operating 
system knows which version is being played. If version 
A is being played and the current block has a 10 pointer 
flag, it means that the next block, an A, should be played 
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after the present one. There is no need for the pointer. 
The pointer is necessary in case version B is being 
played. In this case, since the next block is an A, it 
should not be played. The player should jump to the 
block identified by the pointer -either another C ( or a B 5 
unique to version B being played. 
[0126] Similarly, if version A is being played and the 
current block is a C with code 1 1 for its pointer flag, it 
means that the next block is a B. Since version A is 
being played, the next block should not be played after 10 
the current one. Instead, a jump is made to the A or C 
block identified by the pointer. On the other hand, if ver- 
sion B is being played, the system simply continues to 
the next block. 

[0127] The legend on FIG. 7A shows whether or not 15 
the pointer is used when 1 0 and 1 1 pointer flags are 
found in a C block. The representation 10{P) is an indi- 
cation that the pointer should be used, and a represen- 
tation 10[P] is an indication that the pointer should be 
ignored. It will be recalled that the 1 0 code is used for a 20 
C block when the next block is an A. If version A is being 
played, the pointer is not needed. That is why a transi- 
tion from the C block to the succeeding block, an A, is 
shown by the symbol 10[P]. On the other hand, if ver- 
sion B is being played, since the next block is an A it 25 
cannot be played after the current C. Instead, there 
must be a jump to the block identified by the pointer and 
thus use of the representation 1 0(P) the pointer points 
to either a B block or another C. 

[0128] Similar remarks apply to the representations so 
11 (P) and 1 1[P]. In both cases, it is a C block which is 
being played and the next block is a B. If version A is 
being played, the next block should not be played and 
thus the symbol 1 1 (P) is required to show a state transi- 
tion. On the other hand, if version B is being played, it is 35 
the succeeding B block which should be played, and 
thus the symbol 1 1 [P] is appropriate. 
[0129] The four codes, as well as the usages (P) and 
[P], are depicted in FIG. 7B. Referring to the PLAY B 
transition sequence, the first transition shown is 01 (P). It 40 
will be recalled that the 01 code represents a jump from 
one version to a block of the same version or to a com- 
mon block, and a pointer is required. The first transition 
shown is 01 (P), a jump from a B block to another B 
block The next transition on the PLAY B line is 01 (P), a 45 
jump from a B to a C. Next is an example of the most 
common transition of all, 00, the orderly play of the next 
block after the current block. 

[0130] The fourth transition in the PLAY B line is rep- 
resented by a 10(P) symbol. The 10 code represents a so 
branch from a C block when the next block is an A, the 
example illustrated in FIG. 7B. In such a case, as indi- 
cated in FIG. 7A, if it is version B which is being played 
a jump is made to the block identified by the pointer in 
this case, the next C. 55 
[0131] The 1 1 code is used to identify a branch from 
a C block when the next block is a B. If version B is 
being played, the case under consideration, the pointer 



is not necessary because the next block is to be played. 
That is why the next code shown is 1 1[P]. There follow 
two 00 codes that represent obvious transitions to adja- 
cent blocks, followed by a 1 1[P] code, a branch from a C 
block to the succeeding block which is a B. Finally, a 
jump is made from this B block over the next A block to 
a C block. This requires a 01 (P) code -- the code used 
to jump from a block of either version to a block of the 
same version or a common block. 
[01 32] The PLAY A sequence in FIG. 7B assumes that 
it is version A that is being played. The first four codes 
represent transitions to adjacent blocks, or a jump from 
a block of one version to a block in the same version. 
The next code, 10[P], is used to show a branch from a C 
block to an adjacent A block. The pointer is not used 
since version A is being played, and code 10 is 
employed because the next block is an A block. The 
next 00 code symbolizes the transition from the A block 
to a succeeding C block. 

[0133] Next is a jump from a C block to another C 
block, skipping over two B blocks. The 1 1 code is used 
because this is the code employed when a B block fol- 
lows a C block. The symbol used is 11(P), not 11[P], 
because the pointer is required in going from one C 
block to a C block further down the line. Similarly, the 
next code is again a 11 (P) code to symbolize a branch 
from a C block to an A block further down the line. The 
sequence in FIG. 7B ends with a transition from an A 
block to the next block which is a C, for which the code 
00 is used. 

[0134] The state diagram of FIG. 7A summarizes all 
possibilities. Consider first the state in which an A block 
is being processed, represented by the circle with an A 
in it at the upper left. The two-bit pointer flag in an A 
block is 00 if the next block is also an A (shown by the 
transition from A back to A). If the next block is a B, on 
the other hand, then it clearly should not be played. 
There must be a jump from the A block over the B, either 
to another A or to a C. In either case, the code is 01 (P). 
The drawing shows both a jump over B (to another A), 
and a jump over B to a C. The only other transition from 
an A block is to the next block if it is a C. This is shown 
by the code 00. 

[0135] There are four similar transitions shown for 
state B, i.e., when a data block in version B is being 
read. The 00 code is used if the next block is a B or a C. 
The 01 (P) code is used when the next block is an A, and 
it is jumped over so that the system can next read 
another B or a C. 

[0136] Transitions from a C block are more compli- 
cated because there are seven of them, rather than only 
four as for each of the A and B blocks. If the next block 
is also a C, the code is a simple 00 read the next 
block. If the next block is a B and a jump must be made 
to another C, the code 10(P) controls the jump over the 
A. Similarly, the code 1 1 (P) controls a jump over a B to 
another C. It will be recalled that these two codes are 
used to control branches from a C block, depending on 



21 



BNSDOCID: <EP 0979007A2_I_> 



EP 0 979 007 A2 



42 



41 

whether the next block is an A or B. In either case, if the 
next block is not to be read, it (and blocks like it) must be 
jumped over to the next C. 

[0137] However, after reading a C block, it is also pos- 
sible to read an A or a B. To read an A, one of the codes 5 
1 1(P) or 10[P] is used. The 11 code is employed when 
the next block is a B, in which case the pointer is 
required. The 10 code is used when the next block is an 
A, in which case the pointer is not used. Similarly, to 
read a B block next, either the code 10(P) or 11[P] is 10 
used. The former is employed when the next block on 
the disk is an A, and the pointer is required because this 
block must be jumped over. On the other hand, if the 
next block is a B, the code 1 1 tells the system to go on 
to this next block, and in the process to ignore the 15 
pointer because it is not needed. 
[01 38] Perhaps the most important point to recognize 
is one which is not apparent from the drawings, and that 
is that most blocks will contain 00 pointer flags and no 
pointers. (The 00 code is the only one without a follow- 20 
ing pointer field.) That is because once a frame of either 
version is being played, or once a frame of the common 
material is being played, it is most likely that the next 
frame will be of the same type. Consequently, a 00 code 
alone does the job. The net result is that two versions of 25 
the same motion picture can be stored on the disk, with 
the user having the option of playing either (provided 
that it is allowed by the parental lock), and only a tiny 
fraction of the total disk real estate is "wasted" by 
housekeeping bits that control transitions from one 30 
block to the next block which is to be read after it. Again, 
this is in line with the underlying design philosophy of 
providing maximum flexibility and as many options as 
possible, without unduly wasting bits in the process. 
[01 39] It should also be noted that the invention is not 35 
limited to placing just two versions of a motion picture 
on a disk It is possible to use the same technique with 
three or more versions (although the need for so many 
versions is less likely). In such a case, common blocks 
would require two pointers, not just one. If there are 40 
three versions on the disk, following a C block, the next 
block might be an A, B or D. Two pointers would be 
required to point to the two blocks which are to be found 
further down the line. Obviously, this is just one of the 
changes which would have to be made. The point is that 45 
multiple versions can be accommodated, albeit with an 
expenditure of more housekeeping bits. Nevertheless, 
the total number of pointer bits of this type is still incon- 
sequential compared with the total number of 
audio/video bits. 50 

Data Block Fields 

[0140] FIG. 4 depicts the fields of a data block, and the 
format is similar to that shown for the fields of the lead- 55 
in track in no. 3. Every data block begins with a sync 
word. As discussed above, the sync word pattern can- 
not appear in the data, and thus when it is detected the 



operating system knows that a new data block is about 
to begin. 

[0141] The second field is a 20-bit serial block 
number. All of the blocks on the disk are numbered in 
serial order. The block number is the first thing read 
because it is used by block number/pointer analyzer 47 
in FIG. 2. The block number is essential, for example, 
when jumping from one block to another. The read head 
will usually be positioned at a point near the desired 
block, but it is highly unlikely that the correct block will 
be selected on the first try. This is especially true since 
the number of bits in the data blocks is variable, and the 
system has no way of knowing how many bits there are 
in the blocks being skipped. By reading the block 
number at the start of the data block, the system can 
quickly determine whether the head must be reposi- 
tioned. 

[0142] The third field is a two-bit code which repre- 
sents whether the block is part of the A version, the B 
version, or common to both. (Only three of the four pos- 
sible codes are used.) It might be wondered why the 
system would ever have to check on the version of a 
particular block, since once play of version A or version 
B begins, the pointers discussed in connection with 
FIGS. 7A and 7B will always identify a block which is 
either common or part of the version being played. The 
answer has to do with test forward and fast reverse 
operations. Although these have not been discussed at 
length because they are entirely conventional tech- 
niques, when fast forwarding, for example, the read 
head may be positioned more or less arbitrarily. The 
video should not be shown if it is of the wrong version. It 
is not possible to determine the version of a block simply 
by looking at the block number or the pointer. Neither 
identify the version. It is for this reason that the system 
must be able to determine the version of the block when 
it is first read. 

[0143] Fields 4 and 5 contain the two-bit pointer flag 
and 20-bit pointer which have been explained at length 
in connection with FIGS. 7A and 7B. 
[0144] Field 6 is a one-bit flag which may or may not 
be present Referring to FIG. 3, the video availability flag 
in field 19 tells the operating system whether there is 
any video in the data blocks. Even if there is, however, it 
does not mean that every data block contains video. For 
a system in which there is a single frame represented in 
every data block, and data blocks are processed at a 
fixed rate, there would be video in every data block, 
even if it is "minimal" video which consists of a code rep- 
resenting a "no change." But there may be systems in 
which a data block may represent more or less than a 
single frame. For example, it may be that the video infor- 
mation in a data block, if present at all, is always of the 
same number of bits. Depending upon the compres- 
sion, it may be that many frames are represented in a 
single data block. In such a case, some of the blocks 
would be devoid of video bits. Depending upon the cod- 
ing scheme employed, the bit in field 6 informs the oper- 
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ating system whether there is a field 7 at all. If there is 
video, field 7 contains the video information, terminating 
with a sync word. As mentioned above, the actual cod- 
ing of the video and audio blocks does not comprise 
part of the subject invention. Although MPEG schemes 5 
are preferred, others can be used. 
[0145] Field 8 contains anywhere from no bits up to 
1 6. It will be recalled that field 6 of the lead-in track con- 
tains 100 bit positions, but only N of these (where the 
maximum N is 1 6) can represent bits of value 1 because 10 
there can be at most 16 audio tracks on the disk (of 4 
which M&E is considered 10 be one of them). For each 
of these N tracks, field 8 informs the operating system 
whether there is any audio in the present data block. 
There are thus X "1 "s, up to a maximum of N. The first 75 
bit position of N-bit field 8 corresponds with the first 
audio language track identified in field 6 of the lead-in 
track The second bit in field 8 of a data block is associ- 
ated with the second audio language represented in 
field 6 of the lead-in track, etc. The reason that there are 20 
only N (maximum = 16) bits in field 8 of FIG. 4, rather 
than 100, is that it is known from the lead-in track which 
are the languages that may be present in a data block. 
There is no reason to provide 84 or more bit positions in 
each data block to indicate that the corresponding Ian- 25 
guages are not present when it is known from the lead- 
in track that they are nowhere to be found on the disk. It 
must be borne in mind that the value X in FIG. 4 does 
not equal the value N in FIG. 3. The latter represents the 
total number of audio languages anywhere on the disk, 30 
and its maximum value is 16. The symbol X represents 
how many of those N are actually represented in the 
current data block. 

[0146] Field 9 contains the X audio language blocks. 
Suppose that there are 1 0 audio languages represented 35 
on the disk, but only six of them are represented in the 
current data block. In this case, there would be X bit 
sequences corresponding to the audio languages, each 
ending with an escape character. The escape character 
is used to separate audio blocks from each other. If 40 
whenever an audio block is present it has a fixed dura- 
tion, then, since it is known how many audio blocks are 
present in a data block from the information in field 8, it 
is not necessary to provide a sync word at the end of the 
field. Variable length audio blocks would require a sync 45 
word at the end of the field. 

[0147] Field 9 in the lead-in track contains a value 
from 0 to 63 which represents the number of "other" 
audio tracks. While there may be M such "other" audio 
tracks, as shown in FIG. 3, it does not mean that each of so 
them is represented in the current data block. Field 10 in 
each data block contains M bits, one for each of the 
"other" audio tracks on the disk. Whether the current 
data block actually contains bit information for any of 
these M tracks depends on whether the corresponding ss 
bit position in field 10 contains a 1. If there are Y "1"s 
and Y is less than M, it means that not all of the "other" 
audio tracks are represented in the current data block. 
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Field 11 contains Y "other" audio track blocks, each 
ending with an escape character. It will be appreciated 
that the way the audio tracks and the "other" audio 
tracks are represented in the data block are compara- 
ble. 

[0148] Referring back to FIG. 2, it will be recalled that 
data bits in a data block are distributed to audio buffers, 
a video buffer, a pan scan buffer and a subtitle buffer, as 
well as to master controller 41 over the COM- 
MAND/DATA line 65. Thus far, the representation of 
audio blocks, "other" audio blocks and a video block 
have been considered in the analysis of the fields of 
FIG. 4. Before proceeding with the representation of the 
subtitle data, however, it must be understood that there 
is a difference in the way that subtitle information is rep- 
resented, as opposed to all audio and video data. The 
latter is represented on a block-by-block basis, and the 
buffers are continuously replenished with new audio 
and video data. Subtitles, on the other hand, need not 
change from frame to frame. In fact, a subtitle will not 
even be perceived if it does not remain on the screen for 
more than one frame. Consequently, once subtitle data 
is represented in buffer 59 if FIG. 2, it causes a subtitle 
to be formed on the display and to remain there until 
new subtitle information is loaded into the buffer. To 
remove a subtitle without introducing a new one. a new 
subtitle consisting of a blank field is loaded into the 
buffer. 

[0149] Field 12 in the data block consists of P bits, 
each corresponding with a different one of the P subtitle 
languages identified in field 15 of the lead-in track. (It 
will be recalled that the first position in every 100-bit 
field corresponding to languages does not really repre- 
sent a language, but rather M&E, so that there are a 
maximum of 99 subtitle languages.) Any subtitle for 
which there is an update in the current data block has a 
1 in its corresponding position in field 12. There can be 
up to Z "1 "s, where the maximum value of Z is P. 
[01 50] For each subtitle language for which there is an 
update in the current data block, the update appears in 
field 13. There are Z update blocks, each ending with an 
escape character. It is important to understand that an 
update block can be a blank field. This is the way in 
which a subtitle is removed when a new subtitle is not 
yet to take its place. 

[0151] Field 14 consists of one bit which may or may 
not be present. The field is present only if field 21 in the 
lead-in track is a 1 . In such a case, pan scan information 
is available in the data blocks. If pan scan information is 
available, each data block must tell the operating sys- 
tem whether it actually contains a new starting column 
for the pan scan. Field 14 is a single bit, a flag, which 
indicates whether there is a pan scan update. If the bit 
is a 1 , field 15 is a 9-bit column number, i.e., a pan scan 
update. 

[01 52] Finally, field 1 6 is a single bit which may or may 
not be present, depending on the value of field 30 in the 
lead-in track This one-bit flag in the lead-in track tells 
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the operating system whether supplemental commands 
and data may be present in field 1 7 of a data block. If the 
command/data present flag is a 1 , the command/data 
block is read from field 17. The field ends with an 
escape character. 

[01 53] A data block field thus contains up to six differ- 
ent types of data - audio, "other" audio, video, pan scan 
information, subtitles and a command/data block. 
These are the six types of information which were dis- 
cussed above in connection with FIG. 2, with demulti- 
plexer 63 distributing the different blocks of information 
to the audio buffers, video buffer, pan scan buffer, subti- 
tle buffer and master controller. 

Processing Of The Data Block Fields 

[0154] The processing of the data in a data block is 
relatively straightforward. The processing shown in the 
flowchart of FIG. 6 dovetails with the data block fields 
themselves shown in FIG. 4. 

[0155] It has already been described how block 
number/pointer analyzer 47 on FIG. 2 processes the 
serial block number, version, two-bit pointer flag and 
pointer contained in fields 2-5 of a data block. The next 
field is the video present flag. As shown on FIG. 6, if it is 
determined that video data is present video buffer 55 on 
FIG. 2 is loaded with the video in field 7. If video data is 
not present, the buffer simply has a marker loaded into 
it 

[01 56] It is important to understand the need for mark- 
ers. In order for the operating system always to be able 
to synchronize video, audio, subtitle, etc. information, it 
must be able to tell where in the several different buffers 
is the information from the same data block In other 
words, the operating system must know which part of 
the audio data in an audio buffer goes with which part of 
video data in the video buffer. Otherwise the various 
information items cannot be synchronized with each 
other. By providing markers in the buffers for data which 
is not present in the data blocks, the operating system 
can keep the various items of information synchronized 
with each other. 

[0157] Next, the operating system looks at field 8 to 
determine how many of the N audio tracks on the disk 
(see r IG. 3) actually are represented in the current data 
block. The same is true of the M "other" audio tracks 
represented in field 10. All of the audio and "other" 
audio track data are loaded into their respective buffers. 
The flowchart shows the sequencing only for the first 
and last of the audio tracks. In each case, a test is per- 
formed to see whether the audio track or "other" audio 
track has data present in the current data block. Each of 
the tracks results in something being loaded in its 
respective buffer -- either actual data followed by a 
marker, or a marker alone. 

[0158] After the video and audio information, a data 
block contains subtitle updates. If there is update infor- 
mation for the subtitles in the selected language, it is 



loaded in the subtitle buffer; otherwise a marker alone is 
stored. - The three blocks pertaining to subtitles pertain 
only to a single track, that corresponding to the selected 
subtitle language. 

s [0159] Next, the pan scan update flag in field 14 is 
read. If pan scan update information is present it also 
gets loaded, this time in a pan scan buffer. If no new 
information is available, a marker is simply placed in the 
pan scan buffer to indicate that another data block has 

10 gone by with no new pan scan update information. 
[0160] Finally, the system determines whether there 
are commands or data available (if the lead-in trackf ield 
30 says that commands or data are to be found at all in 
the data blocks). If command/data is present, i.e., field 

15 16 in the dat block is a 1 , it is loaded from field 17 into 
memory in the master controller 41 of FIG. 2. If there 
are no commands or data available only a marker is 
loaded in the microprocessor memory. 
[0161 ] It should be noted that none of the processing 

20 sequences of FIG. 6 shows a check being made 
whether the respective type of information is available 
on the disk in the first place. But it is to be understood 
that a test such as "is command/data present?" really 
consists of two parts. First, is the data block com- 

25 mand/data flag in field 30 of the lead-in track a 0 or 1 ? If 
it is a 0, commands and data are not even looked for 
during the processing of a data block. On the other 
hand, if command or data may be present in a data 
block as a result of the data flag in field 30 of the lead-in 

30 track being a 1, then each data block has its field 16 
checked to see whether the command/data present flag 
is a 1 . It is the value of the flag in the data block field 
which determines whether only a marker gets loaded, 
or a marker following data bits. Similar remarks apply to 

35 the other sequences. For example, there is no reason to 
check whether a pan scain update is present if from the 
lead-in track it is determined that pan scan information 
is nowhere present on the disk. 
[01 62] Although the invention has been described with 

40 reference to a particular embodiment, it is to be under- 
stood that this embodiment is merely illustrative of the 
application of the principles of the invention. Numerous 
modifications may be made therein and other arrange- 
ments may be devised without departing from the spirit 

45 and scope of the invention. 

Claims 

1. A method for controlling operation of a combined 
so player and software carrier therefor, the software 
carrier containing thereon digital data representa- 
tive of picture information having a base aspect 
ratio and including a code indicative of said base 
aspect ratio; the method comprising the steps of 
55 having the player normally represent a default 
aspect ratio but allowing a user to select one of sev- 
eral aspect ratios thereby to change the repre- 
sented aspect ratio from the default to a selected 
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aspect ratio; reading and processing digital data 
read from said software carrier; generating from 
said digital data, in accordance with the repre- 
sented aspect ratio, successive digitized frames; 
and converting said successive digitized frames to 
a corresponding video signal. 

2. A method in accordance with claim 1, further 
including the step of, responsive to said base 
aspect ratio and said represented aspect ratio 
being insufficient to determine the aspect ratio of 
said video signal, providing a user with a choice of 
aspect ratios each consistent with said base and 
represented aspect ratios. 

3. A method in accordance with claim 1 , wherein said 
software carrier includes a code indicative of the 
availability on said software carrier of pan scan 
information; and further including the steps of oper- 
ating on pan scan information read from said soft- 
ware carrier and controlling processing of 
succeeding digitized frames generated from digital 
data read from said software carrier in accordance 
therewith. 

4. A method in accordance with claim 1 , wherein said 
software carrier includes a code indicative of the 
availability on said software earner of pan scan 
information; and further including the steps of oper- 
ating on pan scan information read from said soft- 
ware carrier and controlling processing of 
succeeding digitized frames generated from digital 
data read from said software carrier in accordance 
therewith. 

5. A method in accordance with claim 1 , claim 3 or 
claim 4, wherein said base aspect ratio is 16:9 or 
4:3, and said multiple aspect ratios include 16:9, 
center cut 4:3, pan scan 4:3, and letter box. 

6. A method in accordance with claim 1 , claim 3 or 
claim 4, wherein said digital data on said software 
carrier is in a compressed form, and said process- 
ing means operates at a variable bit rate. 

7. A method for generating a video signal in one of 
multiple aspect ratios from play of a software carrier 
on which is recorded an image program in only one 
aspect ratio, said software carrier including a code 
indicative of the recorded aspect ratio, comprising 
the steps of playing said software carrier to derive a 
signal representative of the image program 
recorded thereon, normally representing a default 
aspect ratio but allowing a user to select one of said 
multiple aspect ratios thereby to change the repre- 
sented aspect ratio from the default to a selected 
aspect ratio, generating a video signal from the sig- 
nal derived from play of said software carrier in an 



10 



aspect ratio which is a function of both the repre- 
sented aspect ratio and the recorded aspect ratio 
indicated by said code, and, responsive to said rep- 
resented aspect ratio and the recorded aspect ratio 
indicated by said code being insufficient to deter- 
mine the aspect ratio of said video signal, providing 
a user with a choice of aspect ratios each consist- 
ent with said represented and code-indicated 
aspect ratios. 

8. A method in accordance with claim 7, wherein said 
image program is recorded on said software carrier 
in digitally compressed form at a variable bit rate. 



15 



9. A method for generating a video signal in one of 
multiple aspect ratios from play of a software carrier 
on which is recorded an image program in only one 
aspect ratio, characterised by said software carrier 
including a code indicative of the recorded aspect 

20 ratio and a code indicative of the availability on said 
software carrier of pan scan information, compris- 
ing the steps of playing said software carrier to 
derive a signal representative of the image program 
recorded thereon, selecting one of said multiple 

25 aspect ratios, generating a video signal from the 
signal derived from play of said software carrier in 
an aspect ratio which is a function of both the 
selected aspect ratio and the recorded aspect ratio 
indicated by said code, and operating on pan scan 

30 information read from said software carrier and for 
controlling in accordance therewith processing of 
the signal derived from play of said software carrier. 

10. A method for generating a video signal in one of 
35 multiple aspect ratios from play of a software carrier 

on which is recorded an image program in only one 
aspect ratio, said software carrier including a code 
indicative of the recorded aspect ratio, comprising 
the steps of playing said software carrier to derive a 

40 signal representative of the image program 
recorded thereon, selecting one of said multiple 
aspect ratios, and generating a video signal from 
the signal derived from play of said software carrier 
in an aspect ratio which is a function of both the 

45 selected aspect ratio and the recorded aspect ratio 
indicated by said code, and wherein said one 
aspect ratio is 16:9 or 4:3, and said multiple aspect 
ratios include 16:9, center cut 4:3, pan scan 4:3, 
and letter box. 

so 
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